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11  ABSniACT  (Mnkmaa  208  words) 

The  DIS  architectare  defines  a  time  and  space  coherent  representation  of  a  virtnai  battlefield  en  vnonment,  measuted  in  terms  of  the 
human  percq>tion  and  behaviors  of  warfighters  interacting  in  free  piqr.  It  provides  a  stractsre  by  which  independendy  developed 
systems  may  interact  with  each  other  in  a  wdl  managed  and  validated  ooti^  simulation  environment  during  all  phaM  of  die 
devdopment  process.  A  fundamental  objective  of  the  DIS  architecture  is  to  provide  a  Moeprint  to  guide  devdopment  of  a  general 
purpose  system  meeting  the  needs  of  a  wide  range  of  users.  The  architecture  must  therefore  nippart  the  broadest  possible  range  of 
userneeds.  At  the  same  time,  the  architecture  and  the  associated  standards  must  provide  sufficient  design  definition  to  achieve  the 
goal  of  tnnqiarent  interoperability  of  a  very  wide  range  of  simulators,  simulatioiis,  and  actual  equipment  operating  on  instrumented 
rangea 
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1.  Netwoirk  Topology 

BDS-D's  goal  is  to  provide  space-time  coherent  battlefields  to  its  users.  6DS-D 
proposes  a  two-tier  architecture  to  meet  this  goal.  Section  3,  Volume  I  of  this 
document  presents  the  architecture,  and  Section  5  of  Volume  I  discusses  related 
network  issues. 

This  section  presents  the  rationale  behind  this  two-tier  architecture.  Section 
1.1  presents  the  architecture.  Section  1.2  lists  the  requirements  the  BDS-D 
hardware  and  software  components  must  meet  in  order  to  successfiiUy  realize  the 
architecture.  Section  1.3  lists  the  evaluation  criteria  for  each  potential  hardware 
and  software  component. 

1.1  DISArcbitecture 

There  are  two  levels  of  abstraction  that  help  to  illustrate  the  architecture.  This 
section  presents  each,  and  explains  how  each  satisfies  or  highlights  architectiire 
requirements.  These  levels  are: 

•  The  DIS  Exercise  Level,  which  highlights  functionality  and 
performance  requirements  for  the  underlying  virtual  networks. 

•  The  Virtual  Network  Level,  which  presents  the  two-tier  architecture, 
and  explains  how  it  can  help  achieve  the  required  levels  of  functionality, 
performance,  interoperability,  and  security. 

1  •  1 . 1  DIS  Exercise  Level 

1.1.1.1  Multipile SimiiltaneoiisEbEercises 

DIS  must  support  multiple  simultaneous  exercises,  shown  in  Figure  1-1. 
Each  DIS  exercise  (e.g.,  the  top  layer  in  the  figure)  is  a  space-time  coherent 
representation  of  the  virtual  battlefield.  Each  DIS  exercise  is  made  up  of  DIS 
entities  and  Simulation  Support  entities.  DIS  entities  are  such  things  as  tanks 
and  helicopters,  and  it  is  a  stated  goal  of  DIS  to  support  upwards  of  10,000  in  any 
one  exercise.  Simulation  Support  entities  are  such  things  as  Data  Loggers  and 
After-Action  Review  facilities.  These  entities  interact  via  the  "DIS  PDU 
Standard,"  defined  in  draft  form  in  "Protocol  Data  Units  for  Entity  Information 
and  Entity  Interaction  in  a  Distributed  Interactive  Simulation." 
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Figure  1-1.  DIS  virtual  networks  support  multiple  exercises. 

1.1. 1.2  PeE^Exerdse  Fidelity 

BDS-D  provides  flexibility  on  a  per-exercise  basis  by  defining  an  exercise  in 
terms  of  several  databases  (Volume  I,  Sections  3  and  4): 

•  The  SIMWORLD  Database 

•  The  BATTLEFIELD  Database 

•  The  SESSION  Database 

Together,  these  databases  specify  the  exercise's  desired  fidelity.  Different 
levels  of  fidelity  may  require  different  levels  of  performance  from  the  underlying 
system.  Volume  n,  Book  I  entitled  "Time^pace  Coherence  and  Interoperability" 
explains  how  fidelity  is  quantitatively  relat^  to  system  performance.  Thus,  on  a 
per-exerdse  basis,  BDS-D  is  required  to: 

•  Deliver  DIS  PDUs  within  a  given  maximum  latency,  and  a  given 
maximum  latency  variance. 

•  Deliver  a  certain  number  of  DIS  PDUs  per  second,  which  is  a  function  of 
the  number  of  DIS  entities  in  the  given  exercise. 

•  Deliver  DIS  PDUs  with  a  drop  rate  below  a  given  maximum,  and  with  a 
bit  error  rate  below  a  given  maximum. 

•  Ensure  secure  operation  at  a  given  security  classification  level. 
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1 .1 .2  Virtual  Netwonk  Level 


This  section  will  present  the  two-tier  architecture  for  DIS  exercises,  and  will 
show  how  the  architecture  fulfills  the  requirements  listed  above. 

1.1.2.1  DIS  Exercise  as  Virtual  Broadcast  Netwoik 


Figure  1-2.  DIS  exercise  as  a  virtual  broadcast  network. 

Figure  1-2  shows  how  a  given  exercise  can  be  thought  of  as  a  virtual  broadcast 
network,  whose  nodes  are  DIS  entities  and  Simulation  Support  Entities.  A  virtual 
broadcast  network  can  be  thought  of  as  a  "community  of  interest,”  in  which 
packets  sourced  by  any  member  of  the  community  are  routed  to  all  members  of  the 
community.  I.e.,  DIS  PDUs  are  broadcast  to  all  ^e  DIS  entities. 

In  order  to  understand  the  follovdng  discussions,  it  is  important  to  understand 
thatDZS  entities  have  "identifiers"  not  "addresses."  For  example,  a  Detonation 
PDU  sent  "from"  entityl  "to"  entity  2  is  in  fact  routed  to  all  the  entities  in  the 
exercise,  so  that  they  may  display  the  impact.  Thus,  entity  identifiers,  even 
though  they  contain  source-host  pairs,  are  not  addresses  which  are  used  for 
routing. 

1.1^^  Two-Tier  Andutectuic:C!e]]s  as  Virtual  Broadcast  Netwoilis 

Although  the  above  single-tier  virtual  broadcast  network  is  appealing  in  its 
simplicity,  several  BDS-D  goals  argue  for  grouping  DIS  entities  into  "cells,"  each 
of  which  is  a  virtual  broadcast  network  as  shown  in  Figure  1-3  below: 
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Figure  1-3.  Upper  tier  virtual  network  connects  multiple  cells  in  a  single  exercise. 

1.  Interoperability  between  DIS  and  non-DIS  (e.g.»  SBVfNET)  gimulators.  If 
the  simulators  do  not  share  a  common  protocol,  a  translator/gateway 
becomes  necessary.  This  results  in  a  partition  into  two  networks,  with  a 
"Cell  Adapter  Unit"  (CAU)  acting  as  a  protocol  translator.^ 

2.  World'Wide  interconnection  of  simulators.  The  two-tier  architecture  is 
intended  to  be  analogous  to  a  WAN/LAN  architecture,  with  the  Virtual 
Intercell  Network  as  a  WAN,  and  the  cells  as  LANs.  There  is  no  reason  for 
the  "virtual  broadcast"  mechanisms  in  each  tier  to  be  common,  shared,  or 
even  the  same.  In  fact,  the  intercell  network  may  elect  to  use  virtual  circuit 
techniques,  and  the  cell  networks  may  elect  to  use  broadcast-based 
techniques. 

1.1.2.3  Two-Tier  Architecture  Supports  Bandwidth  Conservatioii, 
Security 

The  desire  for  security  in  inter-entity  communications,  and  the  desire  to 
conserve  intercell  and  cell  network  bandwidths  can  also  be  further  addressed  by 
the  two-tier  architecture. 


^  Note  that  this  is  essentially  an  0(n)  problem,  where  n  is  the  number  of  entities.  (An  "order  n"  problem 
grows  linearly  with  increasing  n.) 
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Figure  1-4.  The  two-tiered  architecture  supptsts  bandwidth  conservation  and  security. 

Figure  1-4  shows  an  exercise's  virtual  network  divided  into  cell  virtual 
broadcast  networks.  The  partitions  are  bridged  by  Cell  Interface  Units  (CIUs). 
CIUs  are  logical  DIS-level  gateways.^  (Note  that  CAUs  are  CIUs  that  also 
perform  protocol  translation,  and  that  in  Hie  ensuing  discussions,  CIUs  include 
CAUs  unless  otherwise  noted.)  CIUs  can: 

•  Provide  a  ring  of  security  around  the  untrusted  virtual  intercell 
network.  The  CIUs  can  make  content-based  forward/no-forward 
decisions,  and/or  they  can  perform  encryption/decryption. 

•  Manage  traffic  flows  across  the  cell  and  intercell  networks.  Following 
the  SIMNET  long-haul  gateway  example,  CIUs  can  compress  DIS 
packets  based  on  content,  in  order  to  conserve  intercell  bandwidth.3 
They  can  perform  content-based  routing  decisions,  capitalizing  on 
dynamic  multicast  capabilities  of  the  intercell  network  to  preserve  both 
cell  and  intercell  network  bandwidths.  (Note  that  these  schemes  may 
require  as  yet  imstandardized,  non-DIS,  ClU-to-CIU  communication.) 


^  Another  Ofnj  problon. 

^  Con.  rut-based  compression  can  arguably  achieve  a  higher  compression  than  simple  compression  schemes. 
For  instance,  the  Entity  State  PDU  constitutes  the  bulk  of  the  traffic.  One  could  create  a  highly-compressed  Entity 
State  PDU  by  miqiping  the  48-bit  Entity  IDs  to  16-bit  integers,  and  by  eliminating  the  unchanging  information 
(protocol  version,  exercise  id,  three  pad^g  fidds,  force  ID,  both  entity  types,  entity  appearance,  entity  marking, 
ctqiabilities,  and  number  of  articulation  parameters),  saving  49  bytes  out  of  a  minimum  144  bytes  on  each  Entity 
State  transmission.  This  would  result  in  af^roximately  a  34%  bandwidth  savings.  Furtho',  any  compiessitm 
performed  by  the  WAN  is  transparent  to  the  CIUs. 
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*  Promote  interoperability  by  arbitrating  difference  in  databases  between 
cells  of  different  fidelity.^ 

1.2  DIS  System  Requirements 

This  section  lists  the  requirements  for  the  BDS-D  hardware/software  suite  for 
network  components  as  shown  in  Figure  1-5..  The  requirements  are  drawn  from 
the  above  analysis,  and  from  other  indicated  sections  of  this  document.  They  are 
listed  in  the  following  subsections,  in  approximately  decreasing  order  of 
importance. 


Figure  1-5.  The  virtual  netwoik  supptHts  standard  LANs  and  WANs. 

1.2.1  Peifonnanoe 

Performance  is  more  important  than  the  sum  of  all  other  requirements.  An 
interoperable,  secure,  reconfigurable,  cheap  solution  that  fails  to  meet  the 
performance  goals  is  worse  than  useless  because  it  won't  work,  but  it  still  costs 
money. 

Specific  performance  requirements,  in  approximately  decreasing  order  of 
importance: 

•  Ability  to  support  multiple,  nested  virtual  broadcast  networks 

•  High  Throughput,  both  absolute  bandwidth  and  number  of  packets  per 

second 

•  Low  Latency  Variance 

•  World-wide  Interconnection 

•  Low  Latency 


^  Yet  another  Ofnl  problem. 
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•  Low  drop  rate 

•  Low  bit  error  Rate 

•  High  Reliability  and  System  AvailabUity. 

Virtual  broadcast  is  also  called  an  n-way  multicast.  For  small  n,  which  is 
the  number  of  nodes  on  the  virtual  broadcast  net,  n-way  multicast  can  be  built 
out  of  n  1-way  multicasts,  in  which  packets  from  one  specific  member  (hence  1- 
way)  are  routed  to  all  the  others. 

Multicasting  does  not  require  a  connectionless  rather  than  a  connection- 
oriented  hardware/software  approach.  Multicast  support  is  net  limited  to  a 
specific  (OSI)  level  in  the  protocol  stack.  It  does  not  require  a  specific  protocol 
stack.  Furthermore,  the  WAN  and  LAN  multicast  techniques  are  not  required  to 
be,  nor  will  they  likely  be,  the  same.  For  example,  a  connection-oriented 
multicast  can  be  performed  between  geographically  distributed  sites  (based  on 
exercise  ID),  yet  the  individual  simulation  entities  on  a  LAN  at  a  site 
communicate  PDUs  in  a  connectionless  multicast  manner  (for  different 
exercises). 

The  average  rate  of  DIS  PDUs  and  throughput  as  well  as  the  short  term  peak 
PDU  rates  and  throughput  sourced  as  a  function  of  the  number  of  simulation 
entities  are  extrapolated  from  SIMNET  experience  and  DIS  packet  sizes. 

Table  1-1.  Average  long  term  and  peak  shmt  term  sourced  DIS  PDU  rates  and 

throughputs. 


Average  PDU 
Rale 

(PDUs/sec) 

Average 

Tfaroui^^rat 

(Mbps) 

Peak  PDU 
Rate 

(PDUs/aec) 

Peak 

Throii^qrat 

(Mlw) 

1,000 

1,000 

2,500 

3.75 

10,000 

10,000 

15 

25,000 

37.5 

100,000 

100,000 

150 

250,000 

375 

This  is  especially  important  for  the  intercell  network,  which  will  have  to  route 
the  sum  of  the  traffic  from  several  simultaneous  exercises.  The  extremely  large 
number  of  packets  to  be  routed  at  each  cell  interface  means  that  the  per-packet 
routing  service  time  must  be  vanishingly  small. 

Virtual  network  latency  or  delay  is  shown  for  a  virtual  network  connection  for 
two  simulators,  two  LANs,  and  a  commercial  WAN.  Routers  on  each  LAN 
interface  to  the  common  WAN.  Table  1-2  shows  average,  one  standard  deviation, 
and  95th  percentile  virtual  network  latencies  for  OSI  protocol  stacks  (TP4,  CLNP, 
LLC)  for  PDUs  averaging  1500  bits,  and  80%  occupancies  of  communications 
channels  for  different  protocol  processing  CPU  MIPS  at  each  stage,  i.e., 
simulator,  router,  WAN.  The  latency  models  are  extrapolated  from  data  provided 
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by  the  National  Institute  of  Standards  and  Technology  (NIST)  for  OSI  protocol 
stacks  using  0.8  MIPS  processors.  The  queuing  delays  assume  a  M/M/1  model. 

Table  1-2.  Virtual  network  latencies  for  OSI  protocol  stacks  versus  CPU  MIPS. 


CPU  MIPS 

Average 

Latency 

(msec) 

One  Standard 
Deviation  Latency 

(msec) 

95th 

Percentile 

Latency 

(msec) 

1 

500 

500 

1500 

10 

50 

50 

150 

25 

20 

20 

60 

50 

10 

10 

30 

The  number  of  sites  supporting  a  1,000  simulation  entity  exercise  in  BDS-D 
Phase  1  is  expected  to  be  two  to  three.  A  10,000  entity  exercise  in  BDS-D  Phase  2 
would  be  distributed  over  20  to  50  sites.  A  100,000  entity  exercise  in  BDS-D  Phase  3 
is  anticipated  to  be  distributed  over  50  to  200  sites.  World-wide  connectivity  over 
international  commercial  WANs  is  achieved  via  the  interoperability  of  the  OSI 
protocols  based  on  international  agreements  through  the  Consultative  Committee 
on  International  Telecommunications  (CCITT),  a  body  sponsored  by  the  United 
Nations  (UN). 

PDU  network  (LANs  and  WANs)  latency  or  delay  is  anticipated  to  have  a  mean 
of  50  msec  with  95%  of  the  PDUs  serviced  in  less  than  150  msec.  This  model 
includes  queueing  delays  for  network  and  processing  occupancies  of  80%.  The 
system  drop  rate  (excluding  LAN  contention)  due  to  switch  buffer  overflow  is 

anticipated  to  be  less  than  one  in  10*^  PDUs.  The  bit  error  rate  is  anticipated  to  be 
less  than  one  in  10*^  bits.  Commercial  fiber-optic  WANs  today  experience  error 
rates  of  less  than  one  in  10^^  bits.  Network  system  (LAN/WAN  hardware  and 
software)  availability  is  anticipated  to  be  99.9%  based  on  objectives  set  by  LAN 
vendors  and  WAN  Interexchange  Carriers  (DCCs). 

1J2J2  Interoperabifity 

Interoperability  is  a  prime  goal  of  DIS,  because  it  benefits  the  customer  by 
increasing  capability  and  reducing  cost. 

Interoperability  exists  at  more  than  one  level  in  the  two-tier  architecture.  The 
simulator-tO'Simulator  interface  has  already  been  addressed  by  the  DIS  Draft 
Standard.  Interfaces  that  require  further  study  include  the  ClU-to-CIU  interface. 
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which  includes  any  bandwidth-reduction  protocols,  and  the  ClU-to-Intercell 
Network  interface. 

Interoperability  can  be  achieved  through  the  use  of  Open,  multi-vendor,  and 
COTS  standards  based  on  OSI  protocols  from  layers  1  through  3,  subject  to 
performance  requirements  for  throughput  and  latency. 

1^.3  Secmily 

BDS-D  is  required  to  conduct  secure  exercises  at  the  level  of  DoD  Secret  and 
Special  Access  ^ograms  (SAP).  See  Section  7  of  Volume  I. 

1^.4  Recanfigurability  of  N-way  or  1-way  Multicast  Groups 

Although  dynamic  n-way  multicast  is  desirable,  a  per-exercise  configuration 
of  cells  spedfi^  in  the  Session  Database  is  sufficient .  Minimum  advance  notice 
for  network  reconfiguration  is  (TBD). 

Guidance  from  the  Defense  Modeling  and  Simulation  Office  (DMSO)  suggests 
that  virtual  network  configuration  should  be  changeable  on  the  order  of  one  hour 
warning  notice  before  an  exercise. 

1^.5  Cost 

Annual  recurring  costs  of  the  DIS  WAN  are  estimated  using  three  different 
methods  offered  by  commercial  DCCs.  The  first  and  least  expensive  method  is  a 
private  network  of  leased  dedicated  lines  between  DIS  locations.  A  two-tiered 
tandem  arrangement  is  assumed  to  lower  the  cost  estimate  compared  to  a  fully 
interconnected  network  of  (nXn-l)/2  links.  Costs  are  driven  by  the  average  link 
distances  in  airline  miles  between  sites.  Even  though  this  method  is  theoretically 
the  least  expensive,  it  assumes  that  the  connectivity  matrix  between  DIS  sites  is 
static,  hi  reality,  tffis  assumption  is  not  true  and  there  is  often  a  high  chum  rate 
(50%  annually  in  commercial  private  line  networks)  with  resultant  installation 
costs  and  loss  of  long  term  discount  options. 

The  second  method  is  the  flat  rate  basis  of  commercial  frame  relay  services 
that  connect  routers  on  LANs  to  the  local  IXC  Point  of  Presence  (POP).  The  PDUs 
are  then  transported  over  a  shared  backbone  network  with  minimum  bandwidth- 
delay  guarantees  and  the  capability  to  burst  above  the  reserved  bandwidth  to  the 
remaining  bandwidth  of  the  facilities  at  no  extra  cost. 

This  method  is  slightly  more  costly  than  a  static  private  line  network  yet  more 
robust  to  the  dynamic  connectivity  matrix  between  sites  and  surges  in  PDU  rates 
during  exercises. 

The  third  and  most  expensive  method  is  based  on  the  IXCs  charging  by  the 
packet.  In  this  estimate,  the  IXCs  charge  not  on  the  basis  of  sourced  PDUs,  but 
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rather  delivered  (multicast)  packets  and  this  explains  the  high  cost  relative  to 
private  networks  and  frame  relay. 

Figure  1-6  shows  the  cost  estimates  for  the  three  types  of  communications  for 
1,000  simulation  entities  used  40  hours  per  month.  The  entities  are 
geographically  distributed  over  5  to  50  sites. 

1.000  simulated  entities.  40  hours  of  use  per 
month: 

Millions  of  dollars  per  year 


Sites  Sites  Sites  Sites 


Figure  1-6.  Estimated  communications  costs  for  1,000  entities  and  40  hours  use  per  month. 

Figure  1-7  shows  the  cost  estimates  for  the  three  types  of  communications  for 
10,000  simulation  entities  used  40  hours  per  month.  The  entities  are  also 
geographically  distributed  over  5  to  50  sites. 
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10.000  simulated  entities,  40  hours  of  use  per 
month: 

Millions  of  dollars  per  year 
350 
300 
250 
200 
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100 
50 
0 

5  10  20  50 

Sites  Sites  Sites  Sites 

Hguie  1-7.  Estimated  communications  costs  for  10,000  entities  and  40  hours  use  per  mtmth. 
1.3  Ar(ddtectureCompoiiesntEvaluati<m 
1.3.1  Companents  to  be  Evaluated 

Figure  (above,  physical)  shows  the  BDS-D  components  to  be  evaluated: 

•  WAN  Hardware,  and  Software 

•  LAN  Hardware,  and  Software 

•  Internetwork  Protocol  Stacks 

•  CIUs 

•  CAUs 
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1.3^  Network  Management 

This  section  has  two  goals.  The  first  goal  is  to  explain  what  has  been  done  by 
committees  within  the  International  Standards  Organization  (ISO)  to  define  and 
organize  the  services  required  to  perform  communications  resource 
management.  Concepts  and  terminology  relative  to  the  management  of 
communications  resources  are  introduced.  These  resources  are  assumed  to  be 
organized  within  the  framework  of  the  Open  Systems  Interconnection  (OSI) 
Reference  Model. 

Section  1.3.2.1  contains  an  introduction  to  OSI  network  management  with  an 
in-deptii  description  of  the  OSI  Systems  Management  Model. 

Section  1.3.2.2  is  a  presentation  of  the  current  state  of  network  management 
standards  in  1991. 

OSI  Management 

ISO  standards  committees  employ  an  abstract  model,  the  System  Management 
Model,  to  organize  the  services  offered  by  an  OSI  compliant  network  management 
system.  Specific  services  and  protocols  are  defined  in  related  protocol 
specification  standards.  This  section  introduces  the  concept  of  OSI  management 
and  describes  the  Systems  Management  Model. 

The  first  draft  of  the  OSI  Reference  Model  was  introduced  in  1978.  Since  then 
several  extensions  have  been  incorporated  into  the  basic  model.  These  extensions 
provide  additional  functions  used  to  facilitate  information  transfer  within  a  large 
network.  One  of  these  is  the  OSI  Network  Management  extension.  The  OSI 
Management  Environment  is  defined  as  ”that  subset  of  the  total  OSI  Environment 
which  is  concerned  with  the  tools  and  services  needed  to  control  and  supervise 
interconnection  activities  and  managed  objects".  A  managed  object  could  be  a 
piece  of  hardware,  a  software  component  or  a  collection  of  information  such  as  a 
database.  The  object  does  not  need  to  be  an  OSI  resource,  as  it  can  fall  outside  of 
the  framework  established  by  the  Reference  Model.  For  example,  a  Protocol  Data 
Unit  (PDU)  Manager  for  DIS  can  be  defined  as  a  managed  object  outside  the 
framework  of  the  OSI  model. 

ISO  management  standards  address  both  the  syntax  and  semantics  of  the 
information  required  to  accomplish  the  resource  management.  They  also  specify 
the  communications  services  required  to  transport  tMs  information  within  an 
OSI  environment.  The  standards  do  not  specify  how  specific  management 
functions  are  accomplished.  That  definition  falls  imder  the  domain  of  the  user 
application  programs. 

The  OSI/NM  Forum  is  a  group  of  60  vendors  and  service  providers  working  to 
accelerate  OSI  network  management  interoperability.  The  Forum  promotes  the 
use  of  existing  and  draft  stancbrds  as  the  basis  for  interoperability  specifications. 
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Documents  produced  by  the  Forum  include  a  forum  architecture,  protocol 
specification,  object  specification  framework,  and  application  services. 

Figure  1-8  depicts  the  organization  of  resource  management  within  the  OSI 
environment.  OSI  management  focuses  on  the  monitoring  and  control  of 
"managed  objects,"  where  a  managed  object  can  be  any  resource  (hardware  or 
software). 


UMrt 


-dupmw. 
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Figure  1-8.  OSI  management 

As  shown  in  Figure  1-8,  the  systems  management  applications  and  the  user’s 
interaction  with  these  applications  fall  outside  of  the  scope  of  OSI  management 
standards.  Three  forms  of  management  information  exchange  are  defined 
within  the  OSI  management  architecture.  These  are: 


1.  Systems  Management 

2.  Layer  Management 

3.  Layer  Operation 

Systems  management  is  the  preferred  form  of  management  information 
exchange.  Systems  management  provides  mechanisms  for  the  monitoring  and 
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control  of  all  managed  objects.  Systems  management  is  the  only  means  by  which 
OSI  management  of  multiple  layers  is  accomplished. 

Layer  management  provides  for  the  monitoring  and  control  of  managed 
objects  within  a  given  layer.  Layer  management  protocols  should  only  be  used 
when  either  the  systems  management  services  do  not  support  the  exchange  of 
layer  management  information  or  when  the  exchange  is  not  supported  by  higher 
layer  services.  Layer  management  entities  are  processes,  which  are  separate 
from  those  used  to  provide  the  communications  functions.  As  such,  layer 
managers  can  maintain  logs  containing  parameter  values  related  to  specific 
communications  functions  such  as  average  delays  between  entities.  In  addition 
layer  managers  can  test  the  services  provided  by  the  layer  beneath  them. 

Management  fimctions  within  the  communications  protocols  themselves  are 
referred  to  as  layer  operations.  They  differ  from  layer  management  functions  in 
that  as  soon  as  that  instance  of  the  protocol  is  not  needed  the  layer  operations  no 
longer  exist.  Examples  of  information  conveyed  within  the  communications 
protocols  are: 

1.  Error  information  for  that  particular  instance  of  communications. 

2.  Parameters  used  to  modify  the  protocol  during  that  instance  of 
communications. 

3.  Parameters  used  to  control  the  establishment  or  release  of  a 
specific  connection. 

The  things  to  remember  are:  1)  Systems  management  is  the  most  general, 
followed  by  layer  management  and  then  layer  operations,  and  2)  the  preferred 
approach  is  to  use  systems  management  application  processes. 

The  standards  bodies  have  concentrated  on  the  definition  and  standardization 
of  the  services  required  to  support  systems  management  processes.  As  is  typical 
for  OSI  functions,  the  OSI  Management  Functions  are  defined  using  an  abstract 
model  in  this  case  the  Systems  Management  Model.  In  addition  to  the  Systems 
Management  Model  some  of  the  standards  relevant  to  the  implementation  of  the 
model  have  been  agreed  to,  or  suggested.  You  can  view  the  model  as  a  way  to 
organize  the  various  services  required  to  support  systems  management  while  the 
standards  define  sets  of  service  primitives  used  to  provide  the  services. 

Within  the  Systems  Management  Model  the  management  of  a 
communications  environment  is  treated  as  a  distributed  information  processing 
application.  The  interactions  which  take  place  between  management  processes 
are  controlled  by  directives.  These  directives  are  communicated  from  one  process 
to  another. 

Management  processes  are  categorized  as  being  either  a  managing  process  or 
an  agent  process.  Managing  processes  have  overaU  responsibility  for  one  or  more 
specific  management  activities.  Agent  processes  do  the  actual  object 
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manipulations  associated  with  a  request  from  a  managing  process.  This  is 
depicted  in  Figure  1-9. 


Figure  1-9.  Management  process  interactions. 

A  view  of  the  overall  organization  of  the  Systems  Management  Model  is 
depicted  in  Figure  1-10. 


Figure  1-10.  System  management  overview. 

As  shown  in  Figure  1-10,  the  model  consist  of  four  components,  which  describe 
the  manipulation  of  management  information.  The  first  component,  the 
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information  aspect  ,  introduces  the  concept  of  managed  objects  and  the 
information  used  to  describe  these  objects.  Management  activities  are  ultimately 
affected  through  the  manipulation  of  managed  objects.  The  second  component, 
the  functional  aspect  of  the  model,  is  the  functional  grouping  of  management 
activities.  An  example  of  a  functional  grouping  is  fault  management.  You  can 
think  of  a  flmctional  grouping  as  a  basic  user  control  mechanism.  By  organizing 
management  activities  into  functional  groupings,  the  end  user  can  exercise 
management  control  while  remaining  isolated  from  the  actual  details  of  the 
managed  object.  The  third  component,  the  communication  aspect  of  the  model, 
describes  the  communications  services  required  to  convey  management 
information  between  management  processes,  finally,  the  fourth  component,  the 
organizational  aspect,  deals  with  ^e  organizational  requirements  for  managing 
a  collection  of  systems  operating  in  an  OSI  environment.  This  component 
describes  the  requirements  for  assigning  control  of  a  management  function  to  a 
chosen  process  and  the  roles  of  other  processes  (agents)  in  the  achievement  of 
that  function. 

A  managed  object  is  the  OSI  management’s  view  of  a  resource  that  is  subject 
to  management.  This  abstract  definition  provides  the  framework  to  allow  just 
about  anything  to  be  defined  as  a  managed  object.  For  example,  a  connection 
such  as  a  SAP  can  be  a  managed  object  as  well  as  a  piece  of  software  or  a  physical 
piece  of  communications  equipment.  Four  features  of  a  managed  object  are  used 
to  monitor  and  control  its  functions.  These  are: 


1)  The  object's  existence 

2)  The  object's  attributes 

3)  The  object's  states 

4)  The  object’s  relationships 

A  managed  object  exists,  if  it  is  named  in  the  appropriate  database,  and  has  an 
associated  set  of  management  information  that  is  accessible  through  OSI 
management  services.  Included  in  the  management  information  is  the  set  of 
management  operations  that  can  be  performed  upon  the  object  and  the  effect  those 
operations  have  on  the  object.  Characteristics  of  an  object  are  specified  through 
object  attributes.  Attributes  are  descriptions  of  selected  properties  of  the  managed 
object.  When  an  object  is  created,  a  set  of  attributes  is  defined  for  that  object.  The 
values  of  these  attributes  may  be  changed  but  attributes  cannot  be  added  or 
removed.  The  set  of  managed  objects  (names)  in  a  system  along  with  their 
attributes  constitute  the  Management  Information  Base  (MIB)  for  that  system. 
The  model  does  not  define  how  the  MIB  is  distributed.  The  model  dictates  what 
information  is  to  be  included  but  does  not  restrict  the  way  this  information  is 
distributed  within  the  system. 

The  state  of  a  managed  object  represents  the  instantaneous  condition  of  the 
object's  operability  and  availability.  Managed  objects  may  emit  notifications, 
which  are  reports  on  their  states. 
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Relationships  define  the  interdependence  between  managed  objects.  Note  that 
the  model  only  has  to  say  that  features  such  as  relationships  exist.  How  the 
individual  developer  will  provide  the  means  to  determine  and  describe  these 
relationships  will  be  the  difficult  part  of  the  task. 

When  you  consider  the  types  of  services  that  a  user  might  require  to  manage  a 
communication  system,  you're  on  the  track  of  describing  the  fimctional  areas.  In 
ISO  terminology  these  are  referred  to  as  the  Specific  Management  Functional 
Areas  (SMFAsX  There  are  five  specific  fimctional  areas  defined  in  the  model. 
These  are: 


1)  Fault  Management 

2)  Configuration  Management 

3)  Accounting  Management 

4)  Performance  Management 

5)  Security  Management 

The  goal  of  fault  management  is  the  detection  and  monitoring  of  abnormal 
network  operations.  Faults  manifest  themselves  as  particular  events  (errors)  in 
the  operation  of  the  network.  Within  the  OSI  Systems  Management  Model  fault 
management  is  the  set  of  facilities  used  to  manage  error  logs,  accept  and  act  on 
error  notifications,  trace  faults  and  carry  out  sequences  of  diagnostic  tests. 

Configuration  management  provides  for  the  identification  and  control  of 
managed  objects  with  the  goal  of  insuring  the  continuous  operation  of 
communications  services.  Configuration  management  consists  of  the  set  of 
facilities  required  to  initialize  and  dose  down  managed  objects,  to  collect  the  data 
necessary  to  determine  the  system's  configuration  state,  to  change  the 
configuration  of  the  system  (switch  in  standby  equipment)  and  to  assodate  logical 
names  with  sets  of  managed  objects. 

The  goal  of  accounting  management  is  the  determination  of  costs  for  the  use  of 
managed  objects  and  the  establishment  of  charges  for  this  use.  Accounting 
management  consists  of  those  fadlities  which;  i^orm  users  of  incurred  costs, 
enable  the  fixing  of  account  limits  for  the  allocation  of  resources  and  provide  for 
the  combination  of  costs  when  multiple  managed  objects  are  invoked  to 
accomplish  a  communications  task. 

Performance  management  is  the  evaluation  of  the  long  term  behavior  of 
managed  objects.  This  differs  from  fault  management  or  configuration 
management  in  that  both  of  these  tend  to  focus  on  the  immediate  status  of  a 
managed  object  such  as,  "  is  it  on?",  or  "  is  a  standby  available?  "  .  The 
information  used  in  performance  management  is  typically  statistical  data  that's 
analyzed  to  determine  and  predict  trends  in  the  communications  capabilities  of 
the  network. 


Blaztli81,19a2 


17 


ADST/WDL/TR~92-00S010 


SyslMiift  Company 


SI 


The  final  Specific  Management  Function  Area  is  that  of  security 
management.  The  general  idea  of  OSI  Security  Management  is  to  provide  the 
facilities  required  to  implement  an  organization's  security  policy,  as  it  applies  to 
the  communications  aspects  of  a  network.  Specific  functions  included  under 
security  management  are  the  control  and  maintenance  of  access  restrictions,  the 
management  of  encryption  keys  and  the  creation  and  distribution  of  security  logs, 
such  as  access  audits. 

A  management  task  may  require  the  use  of  services  provided  for  under 
multiple  specific  management  functions.  For  example,  "It's  broke,  fix  it!"  would 
require  fa^t  determination  and  isolation  (using  fault  management)  and  systems 
reconfiguration,  such  as  changing  routing  tables  or  switching  in  standby 
eqmpment  (using  configuration  management). 

To  reiterate,  the  purpose  of  this  section  is  for  the  reader  to  understand  how  the 
standards  organizations  define  OSI  Network  Management.  The  tools  used  are:  1) 
a  model  that  organizes  the  required  functions  into  conceptual  groupings,  and  2) 
systems  management  standards  that  detail  how  the  functions  are  to  be 
implemented.  In  describing  the  model  we  have  introduced  the  concept  of 
managed  objects  and  the  grouping  of  management  functions  into  five  general 
categories.  A  third  service  descril^d  by  the  Systems  Management  Model  is  the 
communication  of  management  information. 

The  ability  to  determine  the  status  and  alter  the  configuration  of  managed 
objects  requires  the  exchange  of  management  information  between  cooperating 
systems.  The  communications  aspect  of  the  model  defines  those  services  which 
are  offered  by  the  communications  layers  to  support  the  exchange  of 
management  information. 

Figure  1-11  presents  a  global  view  of  the  communications  required  to  support 
systems  management  fimctions.  A  user's  network  may  include  processing  and 
communications  resources  that  are  provided  by  a  number  of  vendors. 
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Figure  1-1 1.  OSI  communications  support  for  systems  management  processes 


The  goal  of  the  commtmications  aspect  of  the  management  model  is  to  define 
an  architecture  that  will  allow  management  processes  to  exchange  and 
understand  management  information.  As  shown  in  the  figure,  this  exchange 
can  occur  between  management  processes  provided  by  a  single  vendor  or  between 
multiple  vendors'  management  processes.  Interactions  between  management 
processes  are  accomplished  through  the  exchange  of  management  directives. 
The  directives  are  transported  using  OSI  communications  protocols.  To  facilitate 
these  exchanges  a  set  of  common  management  directives  is  used.  The  OSI 
Invtrface  is  the  point  where  the  messages  used  by  the  various  management 
processes  are  mapped  into  the  common  directives,  as  shown  in  Figure  1-12. 
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Figure  1-12.  The  exchange  of  management  directives. 

The  OSI  Interface  provides  communications  services  to  the  application 
processes.  The  services  provided  fall  into  two  categories,  management 
notification  and  management  operation  services.  Notification  services  are 
provided  by  an  Event-Report  function.  This  is  a  generalized  service  used  to  report 
events,  such  as  alarms,  related  to  managed  objects.  Management  operations 
include  the  services  required  to  retrieve  information  on  managed  objects,  to  create 
managed  objects  and  to  request  management  services  from  another  management 
application.  The  OSI  processes  that  provide  communications  services  to  the 
management  applications  are  collectively  referred  to  as  a  System  Management 
Application  Entity,  SMAE. 

A  Systems  Management  Application  Entity  is  constructed  by  grouping 
together  combinations  of  Application  Service  Elements  (ASEs).  An  ASE  is  a  set  of 
functions  used  to  provide  a  specific  communication  service.  For  example,  if  you 
have  written  a  program  and  you  need  to  access  files,  such  as  a  remote  file  server, 
you  would  use  the  File  Transfer,  Access  and  Management  (FTAM)  Application 
Service  Element  (ASE).  ASEs  map  service  requests  ^m  application  processes  or 
other  ASEs  into  a  set  of  common  primitives  used  to  convey  the  requests  to  the 
destination  ASE.  The  destination  ASE  will  translate  the  request  to  an  indication 
which  is  sent  to  the  receiving  application  process.  The  structure  of  a  Systems 
Management  Application  Entity  is  shown  in  Figure  1-13. 
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Figure  1-13.  Systems  management  application  entity. 

The  Common  Management  Information  Service  Element  (CMISE)  is  the 
primary  systems  management  ASE.  CMI^  provides  two  types  of  services  for  the 
purpose  of  systems  management.  The  first  is  the  Management-Event-Report 
service,  which  is  used  to  report  an  event  about  a  managed  object  to  a  peer  CMISE 
service  user.  This  is  the  "something  happened"  service,  llie  second  service  is 
used  to  initiate  management  operations.  This  is  the  "do  something"  service. 
Table  1-3  lists  the  service  primitives  generated  by  CMISE. 
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Table  1-3.  CMISE  service  primitives. 

M- EVENT-REPORT 


M-INmAUZE 
M- TERMINATE 
Management  M  -  ABORT 

Operations  M  -  GET 

M-SET 
M- ACTION 
M-CREATE 
M- DELETE 

To  request  one  of  these  services  the  user's  application  program  would  send  a 
Request  primitive  to  CMISE.  For  example,  a  performance  measure  might 
require  the  retrieval  of  a  munber  that  givt;8  trie  maximum  number  of  connections 
maintained  at  a  specific  SAP.  To  retrieve  this  number  a  performance 
management  message  requedciag  the  M  GET  service  would  be  sent  to  CMISE. 
This  request  message  would  centain  the  information  required  by  CMISE  to 
construct  an  M  -  GET  primitive  to  request  the  specific  piece  of  information.  The 
same  M  -  GET  primitive  could  be  used  in  another  instance  with  different 
parameters  to  rec'^'est  a  different  attribute  value  from  another  managed  object. 

The  Remote  ^  ration  Service  Element  (ROSE)  supports  the  ISO  equivalent  of 
a  remote  procedi:  e  invocation.  This  ASE  provides  services  to  split  a  single 
transaction  into  mtiltiple  requests  and  to  associate  multiple  responses  to  the 
1  riginal  request.  CMISE  uses  ROSE  for  its  request  and  responses.  The  ROSE 
service  primitives  are  listed  in  tabled  in  Table  1-4. 

Table  1-4.  ROSE  service  primitives. 

RO- INVOKE 
RO- RESULT 
RO- ERROR 
RO-REJECT-U 
RO-REJECT-P 
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Association  Control  Service  Elements  (ACSEs)  are  responsible  for  insuring 
that  the  receiving  ASEs  exist  and  that  they  are  capable  of  engaging  in  a  dialogue. 
This  may  require  the  negotiation  of  communication  parameters.  ACSEs  must 
establish  an  association  between  application  entities  before  information  can  be 
exchanged. 

Finally,  in  Figure  1-13,  the  Single  Association  Control  Fimction  (SACF) 
represents  the  rules  used  to  determine  the  order  in  which  the  ASEs  are  invoked 
and  how  information  is  exchanged  between  the  ASEs. 

The  System  Management  ASE  will  provide  the  messages  required  to  ]>erform 
each  of  the  five  specific  management  fimctions  (Fault,  Configuration,  ^curity. 
Accounting,  and  Performance).  A  standard  has  not  yet  been  defined  for  this  ASE. 
The  following  example  clarifies  the  use  of  ASEs.  Suppose  you  have  a  System 
Management  Application  Process  (SMAP)  that  needs  to  convey  an  alarm 
indication  to  another  SMAP.  The  originating  SMAP  would  use  a  function 
provided  by  the  System  Management  ASE  to  communicate  this  information.  The 
service  would  be  called  something  like  "Alarm-Report".  The  Alarm-Report 
function  would  be  included  within  a  library  of  systems  management  services. 
The  SMAP  would  call  this  fimction  with  the  necessary  arguments  to  identify  the 
type  and  source  of  the  alarm.  The  Alarm-Report  fimction  would  then  use  the  M- 
Event-Report  primitive  provided  by  CMISE.  The  idea  is  to  map  any  number  of 
system  management  messages  into  a  much  reduced  set  of  common  primitives. 
Going  back  to  our  example,  CMISE  would  use  the  ROSE  service,  RO-Invoke,  to 
convey  the  alarm  message  to  the  destination. 

The  only  ASEs  currently  required  for  systems  management  are:  1)  The 
Common  Management  Information  Service  Element  (CMISE),  2)  The 
Association  Control  Service  Element  (ACSE)  and  3)  The  Remote  Operations 
Service  Element  (ROSE).  The  File  Transfer,  Access  and  Management  (FTAM) 
ASE  is  included  to  help  clarify  the  purpose  of  an  ASE  and  because  it  is  envisioned 
that  future  Systems  Management  Application  Processes  will  make  use  of  FTAM's 
services. 

The  organizational  aspect  of  the  model  describes  the  highest  level  of 
functionality  required  in  oi^er  to  perform  systems  management.  Recall  that  the 
description  of  the  model's  aspects  started  by  presenting  the  concept  of  managed 
objects,  then  the  services  available  to  manage  these  objects  were  presented, 
followed  by  a  discussion  of  the  communication  services  required  to  convey 
management  information  between  management  processes.  The  organizational 
aspects  serve  to  codify  the  distributed  nature  of  OSI  management. 

Two  or  more  management  application  entities  may  associate  in  order  to 
provide  a  distributed  systems  management  instance.  During  the  course  of  this 
interaction  the  management  entities  may  serve  either  a  managing  or  an  agent 
role.  Each  system  operating  within  an  OSI  environment  may  contain  both 
managing  and  agent  processes,  as  shown  in  Figure  1-14. 
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OPEN  SYSTEM  1 


OPEN  SYSTEM  2 


OPEN  SY 


Figure  1*14.  Roles  of  management  processes. 

The  organizational  requirements  for  managing  a  collection  of  open  systems 
include; 

a)  The  partitioning  of  management  services  into  functional  groups 
with  an  associated  policy  for  each  group.  These  groups  are  the  specific 
management  hmctional  areas  of  fault,  configuration,  accounting,  security 
and  performance  management. 


b)  The  ability  to  assign  and  modify  the  roles  of  manager  and  agent. 


c)  The  ability  to  exercise  control,  in  a  consistent  manner,  over 
resources  owned  by  more  than  one  open  system.  An  example  of  this  would 
be  the  enactment  and  enforcement  of  a  security  policy. 

A  Management  Functional  Domain  (MFD)  is  a  set  of  open  systems  (devices) 
which  has  been  organized  to  meet  the  above  requirements.  The  concept  of  and 
interaction  between  management  functional  domains  is  shown  in  Figure  1-15. 


March  31, 1902 


ADST/WDLmt-92-OOSOlO 


□  Open  System 
Managing  Process 
^  AgentPnoeas 


Figure  1-15.  Structure  of  management  domains. 

As  shown  in  Figure  1-15,  sets  of  management  functional  domains  are 
organized  into  a  Management  Administrative  Domain  (MAD).  This  hierarchical 
organization  is  like  having  local  system  administrators  (MFDs)  who  are  all 
controlled  by  a  group  administration  polity  (MAD).  Management  administration 
functions  are:  1)  the  establishment  and  maintenance  of  authorities  for  each 
MFD,  induding  the  ability  to  modify  MFD  boundaries,  and  2)  the  assignment  of 
resources  (systems)  to  in(hvidual  MFDs. 

OSI  Management  Standards 

The  actions  which  result  in  the  agreement  on  an  ISO  International  Standard 
are  time  consuming.  Because  its  membership  consists  of  standards  organizations 
from  89  different  countries,  half  of  the  time  is  spent  on  technical  considerations 
and  the  other  half  on  political  considerations.  The  process  begins  with  the 
production  of  working  papers.  These  papers  are  typically  written  and  reviewed  by 
a  working  group  witbdn  one  of  the  ISO  subcommittees.  After  agreeing  to  the 
overall  context  of  the  working  paper,  the  work  group  writes  a  Draft  Proposal  (DP). 
ISO  members  have  three  months  to  review  and  comment  on  the  DP.  The  Draft 
Proposal  is  then  revised,  taking  the  received  comments  into  consideration.  The 
res^t  is  issued  as  a  Draft  International  Standard  (DIS).  Members  have  six 
months  to  review  the  DIS  after  which  a  vote  is  taken.  If  75%  of  the  voting 
members  agree  to  the  proposed  DIS,  it  becomes  an  International  Standard  (IS). 
The  process  may  be  further  delayed  by  the  recommendation  of  Proposal  Draft 
Addendums.  The  entire  process  can  easily  span  a  period  of  four  or  five  years. 
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For  conceptual  purposes,  the  entire  spectrum  of  OSI  Management  Standards 
may  be  viewed  as  being  comprised  of  four  elements.  Each  of  the  four  elements 
covers  a  different  aspect  of  systems  management.  The  four  elements  are  model 
definition,  systems  management  functions,  management  information  and 
management  protocols. 

This  set  of  standards  is  given  by  ISO/IEC  7498-4,  OSI:  Information  Processing 
Systems  -  Open  Systems  Interconnection  -  OSI  Management  Framework..  This 
paper,  an  extension  to  the  original  OSI  Reference  Model,  introduces  the  concepts 
of  systems  management,  layer  management  and  communications  protocol 
management  functions. 

Currently,  this  set  contains  seven  items.  Each  item  defines  a  particular 
management  function,  such  as  an  object  management  function,  a  confidence  and 
diagnostic  testing  function  and  an  error  reporting  and  information  retrieval 
function.  Some  of  these  items  reference  the  actual  messages  that  are  to  be 
employed  in  communicating  the  information  required  to  invoke  the  function. 

The  management  functions  are  grouped  into  the  Specific  Management 
Functional  Areas  (SMFAs),  such  as  fault  and  configuration  management.  The 
current  focus  is  to  define  the  required  functions  and  their  related  messages.  Each 
function  and  message  is  assigned  as  a  member  of  one  or  more  SMFAs. 

The  four  papers  in  this  set  describe  the  organization  of  information  used  by 
OSI  management  applications.  One  paper  describes  the  structure  of  managed 
objects,  including  the  concept  of  object  attributes  and  the  process  used  to  assign  a 
name  to  classes  of  managed  objects.  A  second  paper  defines  a  group  of  object 
attribute  types  that  may  be  applicable  to  most  managed  objects.  Included  as  part 
of  the  attribute  definition  is  the  Abstract  Syntax  Notation  (ASN.l)  definition  of  the 
attribute.  This  is  an  ISO  standard  structure  used  to  encode  information  related  to 
the  attribute.  The  third  paper  defines  a  number  of  object  classes  (groupings  of 
managed  objects)  that  may  be  used  as  "superior"  classes  when  defining  new 
classes  of  managed  objects.  The  fourth  paper  essentially  tells  the  reader  how  to 
use  the  first  three  items  in  this  set. 

There  is  only  one  protocol  specifically  designed  to  exchange  systems 
management  information.  This  protocol,  the  Common  Management  Information 
Protocol  (CMIP),  is  used  by  the  Common  Management  Information  Service 
Element  (CMISE).  CMIP  is  defined  in  two  standards.  ISO  9595  defines  the 
services,  i.e.,  CMIS,  used  to  exchange  systems  management  information  while 
ISO  9596  specifies  the  actual  protocol  used  to  provide  these  services.  The  CMIP 
standard  specifies  the  use  of  services  provided  by  another  protocol,  the  Remote 
Operation  ^rvice  Element  (ROSE)  protocol. 

CMIS/CMIP  addresses  acknowledged  limitations  of  the  Simple  Network 
Management  Protocol  (SNMP)  to  communicate  status  of  large  numbers  of 
managed  objects  in  a  structured,  efficient,  timely,  reliable  manner. 
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In  Figure  1-16,  each  supported  protocol  is  referenced  by  name  and  the  ISO 
documentation  related  to  the  protocol. 

I  Systems  Mangement  Application  Process  I 
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Figure  1-16.  Netwcxrk  management  protocol  stack 

1.3.3  Evaluation  Criteria 

1.  Does  each  system  component  help  the  system  as  a  whole  to  meet  the 
above  performance  reqturements? 

2.  Is  the  component  "mature?"  I.e.,  is  it  a  non-developmental  item? 


3.  What  are  the  technical,  cost,  and  schedule  risks  associated  with  the 
component? 
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4.  Will  the  component's  performance  scale  to  10000  entities  and  beyond? 

5.  Does  the  component  help  the  customer  on  his  path  to  GOSIP? 
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2.  lotegratioiiOfHis^ierOkder  Models  into  the  DIS/BDS-D 
Elnviromiieiit 

2.1  Introduction 


The  Integration  of  Higher  Order  Models  (IHOM)  task  defines  and  catalogs  the 
objectives,  tenefits,  and  technology  challenges  associated  with  the  integration  of 
higher  order  models  with  distributed  simulations  such  as  the  Battlefield 
Distributed  Simulation  -  Developmental  (BDS-D).  Higher  order  models  are  those 
models  and  simulations  whose  operations  take  place  at  the  unit  level,  not  at  the 
vehicle  level.  Their  scope  is  mu^  greater  in  breadth  and  depth  of  the  battlefield 
than  the  current  BDSl-D  environment,  but  their  fidelity  of  operations  and  level  of 
time  and  space  resolution  is  considend>ly  poorer.  The  IHOM  task,  conducted  as 
part  of  the  BDS-D  architecture  study,  investigates  opportunities  to  make  use  of 
aggregated  models,  especially  of  models  of  echdons  above  battalion,  to  expand  tlw 
capati^ties  of  BDS-D. 

2.1^2  BaRkgitmnd 

There  is  only  one  physical  world,  but  there  are  many  ways  to  perceive  it.  Ekich 
military  community  perceives  the  real  world  accordu^  to  its  unique  needs  and 
objectives.  For  example,  the  analytical  community  typically  deals  with 
aggregated  models  of  combat  to  allow  many  fast  running  iterations  examining 
weapon  system,  doctrinal,  and  force  structure  trade-offs.  Individual  vehicles  are 
dealt  witb  primarily  in  small  scenarios  and  often  with  a  limited  number  of 
iterations  because  of  the  computer  power  required  to  run  larger  scenarios  at  the 
vehicle  level.  The  training  community,  on  Ibe  other  hand,  normally  deals  with 
vehicle  level  simulations  except  when  training  commanders  and  staff  at  division 
and  higher.  Finally,  the  R&D,  engineering,  and  test  communities  primarily  deal 
with  individual  veMdes  or  weapon  systems,  but  they  are  generally  interested  in 
components  or  modules  of  those  vehides  and  how  well  they  operate  under  various 
conations. 

All  models  are,  in  some  way,  aggregated  models,  i.e.  modules  are  actually 
aggregations  of  parts  and  devices,  veMdes  are  aggregations  of  modules  and 
components,  and  units  are  aggregations  of  vehides  and  other  types  of  platforms. 
The  miyor  distinction  is  that  at  die  lower  level  representations,  devices,  modules, 
and  veMdes  are  physical  elements  that  are  ti^Uy  linked.  A  human  (operating 
himself  as  a  platform  made  up  of  human  subsystems)  can  see  and  touch  modules 
and  vehicles  on  the  battlefield.  Units  are  loosely  coupled  and  are  more 
conceptual.  Companies,  battalions,  etc.  are  physically  represented  on  the  real 
battl^eld  only  t^uf^  their  vehides,  personnel,  supplies,  command  posts,  etc. 
Aggregated  m^ls  use  some  levd  of  unit  as  their  smallest  dement  and  thus  have 
no  direct  physical  analog  on  the  battlefidd.  Thus  there  is  a  strong  rationale  for 
miilting  a  distinction  between  aggregated  models  and  models  at  the  vehide  or 
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platform  level.  In  Distributed  Interactive  Simulation  (DIS),  all  units  (platoons, 
fire  direction  centers,  companies,  and  eventually  brigades,  divisions,  etc.)  are 
represented  by  observable  vehicles  or  platforms.  There  is  considerable  discussion 
on  extending  DIS  into  the  aggr^;ated  unit  world.  This  report  is  one  of  the  first 
steps  in  addressing  that  extension. 

In  addition  to  aggregating  vehicles  into  units,  time,  space,  man-made  effects, 
and  natural  effects  are  also  usually  aggregated  in  unit  level  models.  For 
example,  BDS-D  models  generally  send  Protocol  Data  Units  (PDUs)  several  times 
per  second  with  a  maximum  ui^te  rate  of  fifteen  times  per  second.  Remote 
Entity  Approximation  (REA),  otherwise  known  as  position  extrapolation  or  dead 
reckoning,  then  provides  the  illusion  of  continuous  motion  by  filling  in  between 
the  updates.  Faster  update  rates  can  be  accommodated  by  DIS,  but  they  are  well 
beyond  the  threshold  of  human  perception  and  therefore  beyond  the  general 
bounds  of  DIS.  On  the  other  hand,  it  is  obvious  that  a  lot  of  perceptible  thi]^  can 
happen  in  an  aggregated  model  when  the  length  of  the  time  step  is  firom  one  to  ten 
minutes.  For  example,  individual  air  defense  engagements,  MLRS  volleys,  and 
Hellfire  attacks  occur  in  only  a  few  minutes.  an  aggregated  model,  these 
individual  events  would  generally  be  combined  with  others  that  occurred  during 
the  same  time  period.  Thus,  it  would  be  difficult  to  keep  dose  track  on  cause  and 
effect. 

A  similar  situation  arises  in  resolving  the  spatial  resolution  of  units  in 
aggregated  models.  For  example,  if  units  in  the  model  move  discretely  from 
resolution  cell  to  resolution  cell  (and  do  not  interpolate  or  dead  reckon),  large 
"jumps"  may  be  observed  if  the  resolution  cells  are  on  the  order  of  three  to  ten 
l^ometers  in  width  and  are  a  msjor  part  of  the  screen  display.  On  the  other 
hand,  units  can  be  portrayed  to  move  continuously  even  over  highly  aggregated 
terrain.  In  this  case,  it  is  only  the  interaction  between  the  terrain  and  the  unit 
which  suffers.  For  example,  sectors  and  hexes  generally  are  assigned  a  given 
level  of  roughness,  forestation,  urbanization,  etc.  The  sm^er  the  resolution  ceU, 
the  better  the  resolution.  For  example,  SIMNET  operates  on  100  meter  grid  posts. 
While  at  one  hundred  meters  considerable  detail  can  be  seen  in  the  placement  of 
feat\ires  and  the  general  orientation  of  the  land,  the  terrain  surfoce  is  still  simply 
a  straif^t  surface  stretched  between  these  posts.  As  the  resolution  cells  further 
decrease  in  size  to  ten  and  even  one  meter,  very  highly  detailed  terrain 
representations  can  be  accommodated.  However,  the  computer  power  required  to 
upgrade  terrain  interaction  processing  from  a  sinid®  one  kilometer  box,  to  one 
hundred  ten  meter  boxes,  or  even  to  ten  thousand  one  meter  boxes  for  the  same 
one  kilometer  area  exceeds  that  available  for  most  battalion  level  scenarios. 

Finally,  natural  and  man-made  effects  are  often  simplified  in  aggregated 
models  to  generate  approximations  "appropriate"  to  the  level  of  aggregation  being 
portrayed.  For  example,  weather  is  o^n  played  using  a  simple  fiictor  affecting 
movement  speeds  and  hit  probabilities.  At  the  aggregated  unit  level,  more  detail 
only  increases  precision  without  increasing  accuracy.  For  example,  knowing 
precipitation  rates  to  a  precision  of  two  dedx^  points  is  of  little  value  in  a  model 
which  simply  asks  if  the  weather  is  good  or  bad.  Likewise,  a  detailed 
communications  or  radar  propagation  m(^l  usually  provides  a  representation 
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with  both  atmospheric  and  terrain  effects  considered  in  predicting  the  receiv^ 
power.  An  aggregated  higher  order  model  will  generally  use  a  simple  "cookie 
cutter"  communications  model  with  a  constant  probabilily  of  reception  within  the 
entire  area. 

2.1^  Benefits  of  Liter&diig 

Since  aggregated  models  have  so  many  problems  in  representing  the 
battlefield,  why  would  we  want  to  interfiice  BDS-D  with  them?  The  answer  is  that 
wMe  many  basic  combat  functions  such  as  maneuver  are  aggregated  in  higher 
order  models,  other  Battlefield  Operating  Systems  (BOS)  and  Operational 
Operating  Systems  (OOS)  functions  such  as  intelligence  are  primarily  conducted 
at  levels  above  battalion  and  either  are  not  or  cannot  be  addr^sed  at  the  current 
BDS-D  level.  Also  associated  with  these  higher  levels  are  doctrines  and  associated 
data  bases  for  conducting  operations  which  exceed  the  capabilities  of  a  single 
battalion  to  execute,  but  in  which  a  battalion  would  participate,  e.g.  a  double 
envelopment  or  an  exploitation.  Also,  the  models  and  data  bases  which  generate 
these  BOS  and  OOS  functions  are  automated  in  some  of  the  higher  level  models 
and  could  constitute  the  basis  for  better  representing  higher  level  forces  and 
functions  which  the  battalion  is  likely  to  interact  with  or  be  affected  by.  These 
resources  are  usually  controlled  at  division,  corps,  or  army  level  or  by  another 
Service.  Sensors  su<^  as  Guardrail  and  JffTABS  and  weapons  such  as  ATACMS 
and  BAI  could  potentially  be  added  to  Uie  BDS-D  world  without  the  need  to 
generate  tiiem  ^m  scratch.  Likewise,  the  addition  of  equivalent  higher  level 
enemy  capabilities  which  would  observe  or  engage  the  battalion  as  part  of  the 
extended  battlefield,  increases  the  realism  of  &e  planning  process  occurring  at 
the  battalion.  The  addition  of  these  capabilities  would  increase  the  scope  of  the 
current  BDS-D  and  the  fidelity  of  the  overall  battlefield  simulation. 

Another  reason  for  interfacing  or  integrating  with  higher  level  models  is  the 
general  direction  of  DoD  policy  which  (Orects  the  development  of  common  or 
compatible  standards  across  the  total  reginm  of  military  modeling  and  simiilation 
when  used  for  joint  applications.  Since  there  is  almost  no  scenario  of  interest  for 
larger  forces  which  is  not  joint,  the  poliQr  essentially  directs  all  future  models  to 
comply  with  emerging  standards.  The  advantages  of  interfad^  BDS-D  with 
higher  order  modeU  include  not  only  a  better  context  for  the  vehicle  level  BDS-D 
models  (the  concern  primarily  addressed  here),  but  also  contributes  to  greater 
fidelity  for  the  aggregated  unit  models  by  "tuning"  them  against  vehide  level 
simulations  portraying  an  equivalent  scenario.  The  latter  is  important  because  it 
has  traditionally  been  very  difficult  to  obtain  consistent  results  among  higher 
order  models  or  even  realistic  results  when  compared  to  actual  battles,  tests,  and 
exerdses. 

As  computer  power  and  communications  networking  become  widely  available 
at  reasonable  cost,  the  use  of  Distributed  Interactive  Simulation  (DIS)  standards 
and  common  environments  will  allow  more  simulations  to  interoperate 
seamlessly  throui^  common  representations  at  the  vehide  level  of  detail.  BDS-D 
is  in  t^  forefiront  of  this  movement. 
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2.2  Assumptions 

Based  on  the  requirement  of  IHOM  to  expand  the  scope  and  capabilities  of 
BDS-D,  it  was  observed  that  there  is  little  v^ue  in  interfacing  models  that  are 
essentially  equivalent  in  capability.  This  refers  to  models  that  operate  at  the 
vehicle  level,  but  do  not  represent  higher  organizational  echelons  than  BDS-D  is 
already  providing  in  experiments  such  as  the  Combat  Vehicle  Command  and 
Control  (CVCC)  at  Ft.  Knox  and  earlier  demonstrations  of  SIMNET  such  as 
WAREX  90-3.  Thus,  while  JANUS.  BBS.  and  CASTFOREM  provide  fairly 
realistic  representations  of  the  maneuver  battlefield  and  are  in  widespread  use, 
integrating  tJhem  with  BDS-D  would  involve  considerable  effort,  would  not 
signTdcantly  ei^and  the  scope  of  the  BDS-D  battlefield  or  the  capabilities  of  BDS-D, 
and  would  not  involve  the  use  of  the  DIS  protocols  and  standard. 

It  is  also  assumed  that  the  highest  priority  for  the  addition  of  higher  order 
functions  to  BDS-D  is  automated  command  and  control  of  larger  units  involving 
combat,  combat  support,  and  combat  service  support.  The  second  priority  would 
be  to  acquire  automated  decision  making  routines  for  functions  such  as  the 
allocation  and  automated  response  of  higher  echelon  fire  support  (including 
artillery,  rockets,  attack  helicopters,  and  dose  air  support),  sensor  allocations, 
communications,  etc.  At  a  lower  priority  would  be  routines  to  automatically 
conduct  logistics  support,  transportation,  maintenance,  and  similar  combat 
service  support  functions. 

The  models  addressed  are  primarily  Army  models  and  focus  on  the  ground 
battle  rather  than  the  air  or  naval  environment.  Wherever  possible,  object 
oriented  models  with  joint  capabilities  were  considered. 

Finally,  it  is  assumed  that  in  order  to  show  rapid  progress  in  integration  of 
BDS-D  wi^  higher  order  models,  the  models  recommended  must  be  available  for 
use  and  experimentation  without  a  significant  number  of  conditions  or  costs 
attached.  This  also  implies  that  an  imdassified  version  is  available. 

2.3  Appax»ch 

The  overall  approach  is  shown  in  Figure  1.  It  involves  creating  a  methodology 
to  characterize  Higher  Order  Models  in  terms  useful  to  the  IHOM  task,  collecting 
information  on  the  models  of  most  interest,  assessing  the  models  with  respect  to 
their  ability  to  support  BDS-D  objectives  in  the  short  term,  identifying  taxonomies 
for  integration  of  models,  recommending  particular  models  for  specific 
contributions,  and  developing  an  approach  to  linking  at  least  one  HOM  with 
BDS-D.  If  determined  to  be  feasible,  step  two  experiments  would  then  be  proposed 
to  demonstrate  that  objects  and  messages  generated  in  the  HOM  could  be  passed 
to  the  lower  level  model,  translated  into  DIS  formats,  and  transmitted  over  the 
DIS  network. 
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Figure  1.  Overview  of  Methodology  for  IHOM  Step  One 
2.3.1  Development  of  the  IHOM  Evaluation  Criteria. 

The  initial  step  of  the  approach  identified  and  described  various  higher  order 
models  and  potential  evaluation  criteria.  Step  2  then  analyzed  and  ra^ed  them 
with  respect  to  their  ability  to  interface  with  BDS-D.  Figure  2  provides  an 
overview  of  the  evaluation  criteria  selected  for  this  task.  The  evaluation  criteria 
were  selected  based  on  technical,  administrative,  and  cost  considerations.  Very 
simple  scoring  criteria  were  established  to  rank  order  the  models.  Both  the 
evaluation  criteria  and  the  scoring  definitions  are  described  below. 


IHOM  MODEL  EVALUATION  CRITERIA 


MODEL 

CHARACTERISTICS 

•  REAL  TIME  CAPABLE 

•  OBJECT  ORIENTED 

•  INTERRUPTIBLE 

•  MESSAGE  PASSING 


FEASIBIUTYOF  USE 

•  OPERATIONAL  STATUS 

•  AVAILABILfTY 

•  OPEN  SYSTEMS 

•  EASE  OF  USE 


COST 


•  STAFFING 

•  COMPUTER 

•  UCENSE 


Figure  2.  Hi|^er  Order  Model  Evaluation  Criteria 
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2^1.1  Model  Characteristics. 


One  of  the  most  basic  features  of  BDS-D  is  that  it  operates  in  real  time  as 
perceived  by  the  human  participants,  i.e.  the  model  must  be  capable  of  running  at 
wall  clock  time.  The  modd  must  not  fall  below  real  time  and  must  monotonic^y 
increase  when  viewed  from  the  outside  (intemaUy,  the  model  can  be  implemented 
at  any  speed  as  long  as  it  results  in  the  perception  of  real  time  input  and  output  by 
the  human.  The  model  can  therefore  include  such  features  as  time  warping,  look 
ahead,  and  snap  back  as  long  as  they  are  not  perceptible  to  the  participants.  A 
scoring  of  no  (0)  and  yes  (1)  was  given,  but  if  the  score  was  zero,  the  model  was 
essentially  dropped  from  fhrther  consideration.  With  continuing  advances  in 
computer  technology,  it  should  be  kept  in  mind  that  some  models  which  cannot 
attain  real  time  capability  today  could  do  so  in  the  future. 

To  successfully  interface  with  BDS-D,  the  higher  order  models  must  be  object 
oriented,  i.e.  they  cannot  be  pure,  dosed  form  differential  equations  in  wUch 
specific  locations  of  units  or  vehicles  are  not  maintained.  The  objects  may  be 
aggregated  units  such  as  companies,  battalions,  etc,  but  they  must  have  a  specific 
location  and  discrete  states  which  describe  the  unit's  vehicles,  supplies, 
ammunition,  etc.  The  model  must  also  have  some  reasonable  level  of  fidelity  or  a 
mechanism  for  obtaining  that  fidelity.  The  use  of  ill  defined  strengths  factors, 
such  as  Weapon  Effectiveness  Indices  (WEI)  or  Weapon  Unit  Values  (WUV)  is  not 
acceptable  for  the  purpose  of  this  effort.  *1110  models  considered  were  all  object 
oriented  to  some  degree  with  a  scoring  of  no  (0)  and  yes  (1).  Future  evaluations 
should  further  examine  this  area  to  make  better  distinctions  on  degree  of  object 
orientation  of  the  selected  models. 

The  higher  order  model  must  also  be  interruptible.  This  does  not  mean  that 
the  interruptions  must  be  instantaneous,  however,  the  human  in  the  loop  must 
perceive  that  he  can  input  commands  €is  needed  and  perceive  that  his  commands 
are  being  implemented  in  a  realistic  amount  of  time.  These  times  can  be  quite 
large  in  higher  order  models  since  the  time  between  giving  an  order  to  move  and 
the  unit  actually  moving  can  involve  hours.  This  theoretically  allows  the  use  of  a 
differential  equation  m^el,  if  the  time  steps  are  kept  small.  However,  the  use  of 
closed  form  models  will  place  some  restrictions  on  their  interruptability.  Most 
require  some  minimum  time  to  reach  a  reasonable  solution.  In  this  case,  the 
scoring  was  divided  into  three  levels,  none  (0),  partial  (1),  and  yes  (2). 

Finally,  the  model  must  have  some  explicit  process  of  passing  messages.  It 
can  also  have  implicit  message  passing,  but  there  must  be  a  mechanism  by  which 
simulation  entities  (decision  making  elements)  can  be  isolated  firom  ground  truth. 
The  importance  of  this  separation  of  mental  and  physical  processes  (decision 
makers  from  ground  truth)  is  fundamental  to  acciirately  portraying  the  fog  of  war 
both  for  the  human  participants  and  for  the  computer  generated  decision  makers. 
The  scoring  was  simply  no  (0)  and  yes  (1).  Levds  of  message  passing  capability 
and  the  method  of  separating  mental  and  physical  processes  should  be  considered 
in  future  evaluations. 
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Man>in*the-loop  (MPTL)  was  not  considered  critical  in  the  evaluation  of  h^her 
order  models  to  potentially  link  with  BDS-D,  since  only  the  functions  of  the  higher 
order  model  were  being  evaluated.  However,  if  the  higher  order  model  is  to  be 
used  as  part  of  an  integrated  training  device,  then  foture  evaluations  should 
consider  ^e  ROM's  capabihty  to  allow  realistic  participation  in  the  model. 

2,3J.,2  Ability  to  Use  the  ModeL  (Feasihflity  of  Use). 

The  ability  to  use  a  model  is  dependent  on  a  combizmtion  of  factors  including 
operational  status,  availability,  openness,  and  ease  of  use.  Feasibility  as  v^d 
here  is  as  mudi  a  political  question  as  it  is  a  technical  or  administrative  question. 
First,  the  current  status  of  the  model  is  highly  important.  Since  promises  of 
model  availability  tend  to  be  exaggerated,  it  must  first  be  determined  if  the  model 
is  operational  (has  actually  been  used),  then,  since  the  half  life  of  most  models 
tends  to  be  short,  it  must  be  further  determined  whether  the  model  is  still 
operational.  Secondly,  it  should  be  determined  whether  the  model  has 
C^vemment  sponsorship  and  whether  any  validation  has  been  performed.  Even 
if  a  model  is  operational,  the  availability  of  the  model  may  still  be  in  question  since 
the  associated  data  bases  may  be  dashed  and  therefore  restricted  or  there  may 
be  other  limitations  on  release.  For  the  purposes  of  this  evaluation,  availability 
was  essentially  a  go/no-go  criteria  and  was  not  scored.  An  indication  was  made 
as  to  whether  the  model  was  available  directly  from  the  Government  or  required 
contractor  support.  However,  the  cost  and  difficulty  of  obtaining  access  and 
porting  a  model  to  a  new  environment  could  also  be  considered  an  availability 
factor.  In  this  case,  there  would  be  nuyor  differences  among  the  models. 

Also,  while  not  a  major  restriction  in  research  programs,  the  "openness"  of 
the  model  has  to  be  considered.  The  use  of  proprietary  h^dware  and  software  did 
not  preclude  consideration  of  any  models  for  this  effort  and  was  not  scored.  But 
increasingly,  it  impacts  on  decisions  concerning  whidi  models  get  Government 
support  and  which  do  not.  The  evaluation  of  openness  was  based  primarily  on  the 
use  of  proprietary  systems.  In  this  evaluation,  UNIX  (regardless  of  which 
version)  was  considered  an  open  system.  In  future  evaluations,  consideration 
can  be  made  of  the  language  used  (Ada  is  the  Government  standard)  and  whether 
or  not  the  computer  system  is  Government  Open  System  Interface  Protocol 
(GOSIP)  compliant  in  its  communications  capability.  Note  that  while  Ada  is  the 
Government  software  standard,  it  is  not  an  object  oriented  language  and 
techniques  for  mAlring  it  object  oriented  are  not  standardized,  as  yet 

Finally,  the  ease  of  use  of  the  models  is  characterized  in  terms  of  the  type  and 
skill  level  of  manpower  required  to  operate  it  (including  controllers,  surrogate 
players,  and  operators),  the  ease  or  difficulty  of  the  Soldier  Machine  luteiface 
(SMI),  and  the  general  complexity  of  the  model.  The  last  item  was  not  considered 
a  general  restriction  on  the  use  of  a  particular  model,  but  could  have  an  impact  on 
cost  and  schedule  due  to  time  required  to  learn  the  model  or  the  difficulty  in 
linking  with  or  modifying  the  model  in  the  timefirame  desired.  The  scoring  for 
ease  of  use  v/as  hard  (0),  medium  (1),  and  relatively  easy  (2).  A  broader  scale  may 
be  of  use  to  future  evaluations. 
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2^^  Costs. 


Costs  were  not  evaluated  in  detail,  but  the  amount  of  manpower  required,  the 
size  of  the  associated  computer  facility,  and  whether  or  not  a  Ucense  was  required 
were  considered.  The  basis  for  characterization  of  staff  size  was  small,  less  than 
six  personnel  and  large,  more  than  twenty.  This  includes  controllers,  system 
maintainers,  and  other  non-player  personnel.  The  basis  for  scoring  of  staff  size 
was  large  (0),  medium  (1),  and  small  (2). 

The  computer  facility  evaluation  was  based  on  a  scoring  of  mainframe  (0), 
minicomputer  (1),  and  workstation  (2)  for  the  purposes  of  this  relatively  small  and 
low  cost  experiment.  None  of  the  models  considered  required  a  license  and  it  was 
dropped  as  an  evaluation  criteria.  With  the  emphasis  on  open  systems,  it  is  not 
expected  that  it  will  be  a  criteria  in  future  studies  unless  a  proprietary  system  is 
selected. 

2.3J2  Model  Evaluations. 

A  first  order  evaluation  was  conducted  using  sources  such  as  the  JCS 
Wargaming  Catalog  and  the  DDR&E(T&E)  Handbook  of  Models.  A  first  order 
selection  was  then  made  based  on  very  basic  criteria  such  as,  does  this  model 
portray  ground  combat  and  is  it  still  operational.  This  selection  yielded  a  few 
more  than  a  dozen  ground  battle  models  which  are  in  common  use  and  appear  to 
have  types  of  functions  not  available  to  BDS-D  level  (vehicle  level)  models.  Several 
of  the  models  in  widespread  use  were  at  the  same  level  of  resolution  as  BDS-D  and 
provided  little  capability  beyond  that  already  represented  in  BDS-D.  These  models 
such  as  JANUS,  BBS,  and  CASTFOREM  are  listed  below,  but  they  are  not  further 
considered  as  potential  higher  order  models  for  the  purposes  of  these  evaluation. 

The  second  order  evaluation  considered  two  groups  of  models.  One  group 
operated  only  at  Echelons  of  Corps  and  Below  (ECB)  and  the  other  depicted 
operations  at  theater,  which  can  also  be  referred  to  as  Echelons  Above  Corps 
(EAC).  Only  one  of  these  models,  the  Corps  Battle  Simulation  (CBS),  is  currently 
in  widespread  use  in  the  Army  training  community.  However,  the  higher  level 
Battlefield  Operating  System  (BOS)  and  Operational  Operating  System  (OOS) 
functions  of  interest  were  found  in  each  of  them  to  varying  degrees. 

Of  the  theater  level  models,  both  the  Joint  Theater  Level  Simulation  (JTLS), 
and  Joint  Wars  along  with  its  component,  the  Ground  Warfare  Simulation 
(GRWSIM)  are  currenUy  used  in  the  training  community.  JTLS  is  in  use  at  the 
Joint  Waxiare  Center  and  GRWSIM  at  the  Warrior  Preparation  Center.  Plans 
are  also  underway  to  expand  the  role  of  joint  level  models  in  new  training  centers 
such  as  Korea.  However,  as  with  the  corps  level  models,  certain  higher  level 
functions  appeared  to  be  available  within  each  of  several  theater  level  models  and 
five  were  considered  in  more  detail  as  candidates  to  interface  with  a  DIS 
compliant  BDS-D  vehicle  level  simulation. 
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A  short  overview  of  each  hifi^er  order  model  is  given  below  followed  by  an 
overall  ranking  of  the  HOM  according  to  the  evaluation  and  scoring  criteria 
described  above.  The  HOM  rank  ordering  was  based  on  scores  for  real  time 
capabilities,  interruptability,  object  orientation,  message  passing,  ease  of  use, 
staffing  requirements,  and  computer  resources.  The  maximum  score  possible 
was  eleven  and  the  average  score  was  approximately  seven.  Since  all  the  models 
which  survived  the  initial  screening  are  currently  in  use  in  the  Government,  they 
were  all  considered  to  be  available.  However,  it  was  obvious  that  for  the  same  cost, 
some  models  were  much  more  available  than  others. 

2.3^  Selection  and  Rankingof  the  Models. 

The  models  were  initially  placed  in  three  generic  categories  representing  the 
highest  echelon  of  the  battlefield  which  they  represented.  The  first  category  was 
models  up  to  brigade.  The  second  category  was  models  with  the  highest  echelon 
at  corps  and  the  third  category  was  echelons  above  corps.  After  an  initial 
evaluation,  it  was  determined  that  BDS-D  would  not  sign^Scantly  benefit  finom 
interfacing  it  with  any  of  the  models  in  the  first  category  as  they  basically 
duplicate  ^e  level  of  operations  already  available  in  BDS-D.  Category  1  models 
are  provided  here  for  completeness,  but  they  are  not  evaluated  for  the  purposes  of 
linking  them  to  BDS-D. 

2,3^.!  Category  1:  Lower  Levd  Models. 

The  lower  level  models  considered  in  this  task  are  the  Brigade-Battalion 
Simiilation  (BBS),  the  Battalion  Combat  Model  (BCOM),  the  Combat  Arms  Task 
Force  Engagement  Model  (CASTFOREM),  and  JANUS.  Each  of  these  models  is 
discussed  below. 

a.  Brigade-Battalion  Simulation  (BBS).  The  BBS  model  is  currently  in  use 
throughout  the  training  community.  Its  current  implementation  exercises  a 
brigade  or  battalion  staff  along  with  subordinate  commanders.  It  is  implemented 
at  the  individual  weapon  system  level  and  provides  a  computer  generated  plan 
view  display  of  tanks,  aircraft,  and  their  engagements  with  enemy  forces.  It  is 
manpower  intensive  to  operate,  but  efforts  are  underway  to  increase  its  levd  of 
automation.  BBS  runs  on  the  Army  Family  of  Simulations  (FAMSIM)  hardware 
suite  which  is  basically  DEC  VAX™  minicomputers  and  Amiga  display  devices. 

b.  Battalion  Combat  Model  (BCOM).  BCOM  was  developed  for  the  Army 
Research  Institute  (ARI)  using  data  collected  from  field  tests  emd  exercises 
conducted  at  Ft.  Hunter-liggett.  The  model  provides  detailed  three  dimensional 
displays  of  vehicle  level  views.  The  model  can  be  run  in  an  interactive  mode  and 
is  currently  resident  on  both  SUN™  and  Silicon  Graphics™  (SGI)  workstations. 
While  it  portrays  human  decision  making,  it  has  only  recently  been  used  in  a 
man  in  the  loop  mode  of  operation. 

c.  Combat  Arms  Task  Force  Engagement  Model  (CASTFOREM). 
CASTFOREM  is  primarily  used  by  the  a^ysis  community  to  examine  new 
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weapon  systems  or  changes  to  front  line  combat  elements.  It  has  highly  detailed 
terrain  and  vehicle  representations  and  consequently  when  portraying  large 
numbers  of  vehicles,  it  often  operates  slower  than  real  time.  It  is  operational  on 
DEC  VAX™  equipment,  but  requires  considerable  experience  to  operate. 

d.  JANUS.  JANUS  was  originally  developed  by  the  Lawrence  Livermore 
Laboratories  as  an  analysis  tool,  but  it  has  been  adapts  for  training  and  is  now  in 
widespread  use  as  a  member  of  the  Army  FAMSIM.  It  has  a  user  fxiendly 
interface  and  operates  on  several  types  of  computers  It  is  most  often  implemented 
on  DEC  VAX™  equipment.  It  provides  a  color  map  based  plan  view  display  of 
individual  vehicles  with  intervisibility  considered,  but  is  limited  in  the  size  of  its 
battlefield. 

e.  These  and  several  other  models  which  simulate  combat  operations  at  the 
vehicle  level  of  detail,  overlap  BDS-D  significantly,  and  consequently  have  little  to 
offer  BDS-D  through  linking.  In  the  context  of  this  evaluation,  they  are  not 
considered  higher  order  models.  On  the  other  hand,  several  of  them  contain 
algorithms  and  data  bases  that  should  be  considered  for  incorporation  into  BDS-D 
as  it  expands  and  the  models  themselves  might  be  used  as  portals  to  the  BDS-D 
network.  Further  investigation  of  these  topics  is  left  for  future  efforts. 

2,3^  Categoiy2l:  Echelons  Coips  and  Below. 

The  models  evaluated  at  echelons  corps  and  below  included  the  Corps  Battle 
Simulation  (CBS),  the  Corps  Battle  Analyzer  (CORBAN),  the  Combat  Sample 
Generator  (CORSAGE),  and  the  EIAGLE  Corps/Division  An^ysis  Model. 


Table  1.  Evaluation  of  Applicable  Coips  Level  Models 


Criteria 

CBS 

COBBAN 

EACBJB 

Real  Time 

Y 

Y 

Y 

Y 

Objects 

Y 

Y 

Y 

Y 

Interrupts 

Y 

P 

P 

Y 

Messages 

N 

Y 

N 

Y 

Available 

G 

C 

G 

NA 

Open 

VMS 

UNIX 

VMS 

UNIX 

of  Use 

H 

E 

M 

E 

Staff  Sue 

L 

S 

S 

S 

Computer 

Mini 

WS 

Mini 

WS 

Score 

5 

8 

7 

11 

a.  Corps  Battle  Simulation  (CBS).  The  CBS  model  is  a  direct  descendent  of  the 
Joint  Exercise  Simulation  System  (JESS)  developed  by  the  Jet  Propulsion 
Laboratory  spedficaUy  for  ground  force  training  at  the  corps  and  below.  It  scored 
well  in  basic  capabilities,  but  lost  points  due  to  the  size  of  the  staff  needed  to 
operate  it  and  the  difficulty  of  obtaining  such  a  large  staff  in  a  research 
environment.  CBS  is  particularly  manpower  intensive  when  conducting  a  multi¬ 
corps  scenario  as  envisioned  by  this  effort.  If  a  Battle  Command  Training 
Program  exercise  were  scheduled  using  CBS,  it  could  provide  the  environment 
necessary  to  utilize  it  in  experiments  with  BDS-D.  However,  there  would  be  few 
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opportunities  to  repeat  experiments  with  the  CBS  model  without  extensive 
external  support.  Even  if  IHOM  experiments  were  able  to  "piggy  back"  on  BCTP 
exercises,  the  potential  would  exist  for  disrupting  the  training  exercises  which  is 
an  unsatisfactory  situation.  It  should  be  noted  that  extensive  efforts  are 
underway  to  link  CBS  with  the  USAF  AWSIM  model  as  imrt  of  the  Ag^egate 
Level  Simtdation  Pro<4>col  (ALSP)  program.  Consideration  is  also  being  given  to 
linking  CBS  (hrectiy  to  the  SIAO^T  v^de  level  simulators. 

b.  Corps  Battle  Analyzer  (CORBAN).  CORBAN  was  originally  used  as  a 
seminar  trainer  and  is  currently  in  use  as  an  analsrtical  model  where  it  is 
recognized  for  its  ability  to  realistically  represent  command  and  control  functions. 
Its  ability  to  automatically  generate  more  detailed  lower  level  orders  based  on  the 
model's  perception  of  the  battlefield  is  relatively  unique.  Only  the  Eagle  model  has 
a  similar  capab^ty.  COBBAN  has  recently  l^en  rehosted  in  UNIX  on  a  desktop 
workstation  (SUN).  While  CORBAN  is  currently  operating  only  in  batch  mode,  its 
architecture  is  object  oriented  and  supports  real  time,  interruptible  operations. 
Earlier  versions  of  CORBAN  used  man-in-the-loop  and  that  capability  could  easily 
be  reinstated.  The  COIffiAN  model  has  recentiy  implemented  on-screen  input 
capability  as  part  of  ^  soldier  machine  interface. 

c.  Combat  Sample  Crenerator  (CORSAGE).  The  CORSAGE  model  has  been 
used  extensively  as  an  analytical  tool  to  produce  scenario  data  in  which  to 
evaluate  trade-ofis  primarily  in  weapon  systems.  It  has  not  been  used  in  training 
and  is  not  fidly  interruptible  by  a  man  in  the  loop.  CORSAGE  is  relatively  easy  to 
use,  but  requires  some  experience  in  its  use  since  it  is  oriented  to  the  analyst 
rather  than  the  warfighter. 

d.  EAGLE.  The  Eagle  Corps/Division  Analysis  Model  will  provide  a  new 
dimension  in  corps  level  combat  simulation  with  highly  detailed  rather  than 
aggregated  representations  of  close  combat  and  the  terrain  on  which  it  is 
conducted.  In  addition,  it  will  have  an  extensive  command  and  control  structure 
with  explicit  communications  between  all  decision  making  nodes.  It  is  highly 
automated  and  can  be  run  by  a  single  operator.  It  is  time  stepped,  making  it  most 
useful  as  a  seminar  trainer,  but  based  on  its  open  architecture,  it  shoiild  be 
modifiable  to  be  fully  event  interruptible.  Eagle  is  currently  in  its  final 
developmental  stages  and  should  be  available  for  use  outside  of  TRAC  in  eight  to 
ten  months  if  the  current  LISP  variant  is  used.  In  the  meantime,  efforts  are 
ongoing  to  directly  link  it  with  SIMNET  vehicle  level  simulators  as  part  of  an 
Army  proof  of  principle  demonstration. 

Based  on  the  evaluation  criteria,  EAGIiE  is  by  tax  the  preferred  model  to  use 
for  the  proposed  linkage  of  a  corps  level  model  and  DIS  compliant  BDS-D  vehicle 
level  simulations  and  simulators.  However,  the  EAGLE  model  is  under  the 
control  of  the  TRADOC  Analysis  Command  (TRAC)  and  since  it  is  heavily 
involved  in  an  effort  to  inter&ce  with  SIMNET  simulators,  there  is,  as  yet,  no  easy 
way  to  access  the  model  for  the  type  of  effort  envisioned  here  . 
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2.3.3^  CategDiy3:  Theater  aiidEchekMis  Above  Cogps  Level  Models. 

Five  models  at  the  theater  level  of  8a>pe  were  evalimted  using  the  same  criteria 
and  scoring  schema  as  for  the  corps  level  models.  These  m^els  included  the 
Combat  Evaluation  Model  (OEM)  and  its  relatives  such  as  FORCEM,  Joint  Wars 
or  the  Ground  Warfare  Simulation  (GRWSIM),  the  Joint  Theater  Level 
Simulation  (JTLS),  the  METRIC  model  of  Joint  Operations,  and  VECTOR  in 
Commander  (VIC).  The  Concurrent  Theater  Level  Simulation  (CTTLS)  and  the 
Dynamic  Ground  Target  Simulator  (DGTS)  were  also  considered  to  be  candidates 
for  future  evaluations. 


Table  2.  Evaluation  of  Applicable  Theater  Level  Models 


Criteria 

GEBC 

JTWABS 

JOB 

MEnUC 

VIC 

Real  Time 

Y 

Y 

Y 

Y 

Y 

Objects 

N 

Y 

Y 

Y 

N 

Interrupts 

N 

Y 

Y 

Y 

P 

Messages 

N 

P 

N 

Y 

N 

Available 

G 

G 

G 

C 

G 

Open 

VMS 

VMS 

SIMSCRIPT 

UNIX 

VMS 

of  Use 

M 

M 

E 

E 

E 

Staff  Size 

S 

M 

S 

S 

S 

Computer 

Mini 

Mini 

Mini 

WS 

Mini 

Score 

5 

7 

8 

10 

7 

a.  Combat  Evaluation  Model  (CEM).  CEM  and  its  offshoots  are  essentially 
large  scale  differential  equation  models  with  little  chance  of  adaptation  to  a  real 
time,  man-in-the-loop,  interactive  training  environment.  Its  primary  advantage 
is  that  it  has  a  long  history  of  use  and  a  number  of  experience  users.  However, 
without  an  object  orientation,  it  would  be  difficult  to  extract  functions  from  the 
model.  Some  data  bases  may  still  be  applicable,  but  the  time  available  for  the 
follow-on  to  this  effort  (approximately  six  months)  precludes  further 
consideration  of  the  model. 

b.  Joint  Wars  (GRWSIM).  The  Ground  Warfare  Simulation  (GRWSIM)  is  the 
land  component  of  the  Joint  Wars  model  being  used  and  further  developed  for  the 
Warrior  Preparation  Center  (WPC)  and  potentially  other  joint  wargaming 
centers.  The  model  is  undergoing  modifications  to  improve  its  play  of  several 
combat  support  and  combat  service  support  functions.  As  part  of  the  Distributed 
Wargaming  System  (DWS),  it  has  also  b^n  interfaced  to  a  Deep  Attack  (Follow  On 
Forces  Attack  or  FOFA)  model,  an  electronic  warfare  model,  and  several 
additional  models.  GRWSIM  is  used  for  training  and  has  most  of  the  attributes 
needed  to  provide  a  highly  credible  environment  fbr  this  experiment.  However,  in 
its  current  form,  it  is  manpower  intensive  for  the  type  and  scope  of  operations 
envisioned  in  this  effort.  Furthermore,  it  draws  several  of  its  BOS  and  OOS 
functions  such  as  intelligence  from  external  models. 

c.  Joint  Theater  Level  Simulation  (JTLS).  JTLS  has  been  in  use  in  the 
analytical  community  for  several  years.  It  is  object  oriented  and  interruptible,  but 
has  been  primarily  used  for  corps  level  scenarios  with  emphasis  on  dose  combat. 
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Efforts  are  underway  to  expand  its  representation  of  both  rear  and  deep 
operations.  It  is  written  in  SUBSCRIPT™  and  has  extensive  documentation,  but 
has  been  used  more  as  an  analytical  model  than  as  a  man  in  the  loop  training 
simulation.  Several  joint  level  organizations  are  examining  JTLS  for  applicability 
as  a  truly  joint  level  model. 

d.  METRIC.  METRIC  is  an  expansion  of  the  Army  Integrated  Corps  (ICOR) 
model  to  theater  level  with  the  edition  of  considerable  air  and  combat  service 
support  portrayal.  It  has  been  used  for  both  closed  form  and  man  in  the  loop 
evaluations.  It  is  object  oriented  and  has  detailed  communications  and 
intelligence  representations  with  explicit  message  passing.  It  is  a  top  down 
model  which  has  global  capability  allowing  for  simulation  of  multiple 
simultaneous  theaters.  It  also  has  an  adjustable  resolution  cell  (hex)  allowing 
the  model  to  operate  at  different  levels  of  resolution  without  changing 
software.(8ome  data  must  be  changed).  METRIC  has  recently  been  rehosted  in 
UNIX  on  a  SUN™  workstation.  It  runs  in  real  time  for  a  hill  theater  scenario 
including  extensive  fixed  wing  and  helicopter  operations.  METRIC  is  not  a 
Government  sponsored  model,  but  has  been  made  available  to  the  Government  at 
several  locations. 

e.  VECTOR  in  Commander  (VIC).  VIC  represents  a  multi-corps  theater  and 
runs  in  real  time.  It  is  primarily  a  differential  equation  model  which  has  been 
extensively  modified  to  give  it  many  of  the  diaracteristics  of  an  object  oriented 
model.  It  is  not  generi^y  used  for  man  in  the  loop  evaluations,  but  could  be 
modified  to  provide  that  capability.  Because  it  is  not  strictly  object  oriented,  any 
fimctions  extracted  from  VIC  would  be  difficult  to  apply  to  BDS-D. 

Based  on  the  evaluation  criteria,  the  METRIC  model  has  a  dear  advantage 
over  the  other  theater  level  models  considered.  Its  strengths  lay  primarily  in  its 
message  passing  capability  and  its  ease  of  use.  The  latter  is  a  function  of  a 
relatively  simple  interface,  the  ability  to  run  the  model  with  as  few  as  two  players 
(or  to  repeat  wargames  with  no  man  in  the  loop),  and  the  fsct  that  it  can  be  run  on 
a  relatively  small  workstation. 

2.4  Rxamlnatinfn  «f Mndrf 

Regardless  of  what  models  are  selected  firom  the  evaluation,  they  will  stiU  have 
to  be  linked  to  BDS-D  through  some  mechanism.  There  are  a  several  of  ways  to 
link  models  and  they  have  met  with  varying  degrees  of  success.  The  following 
section  discusses  several  of  these  methods  and  evaluates  them  with  respect  to  the 
objectives  of  integrating  higher  order  models  with  BDS-D. 


BSaidi31,19fl2 


41 


ADST/WDL/TB-82-00S010 


• 

Direct  Intertaee  -  Horizontal 

DWS&SIMNET 

• 

Direct  Interface  •  Vertical 

AMiP 

• 

Networked  Integration  •  Horizontal 

ALSP  &  Data_bus 

• 

Networked  Integration  -  Vertical 

SWEG 

• 

Networked  Integration  •  Hybrid 

BDS-D 

• 

Framework  Models  -  Hybrid 

NTB&  METRIC 

• 

Parallel  Processing 

CTLS  &  DGTS 

• 

Encapsulation 

STAFKA 

Figure  3.  There  are  Several  Simulation  Linking  Technologies 
Available.  Each  has  Advantages  and  Disadvantages. 


a.  Direct  Interface  -  Horizontal.  One  of  the  most  popular  approaches  to 
linking  models  and  simulations  is  the  direct  horizontal  linl^e  of  several 
independent  models  at  approximately  the  same  level  of  detail.  The  largest 
example  of  this  is  the  Distributed  Wargaming  System  (DWS)  at  the  Warrior 
Preparation  Center  where  seven  separate  models  have  been  linked.  In  this 
approach,  a  unique  linkage  is  established  between  each  of  the  models.  However, 
as  the  number  of  models  increases,  the  number  of  model  linkages  increases 
geometrically.  The  result  is  large  amounts  of  unique  linkage  code  that  has  to  be 
maintained  in  addition  to  the  models.  The  approach  works,  but  it  involves 
considerable  effort  and  it  does  not  utilize  a  set  of  standards  to  expand  the  concept. 

K  Direct  Interface  •  Vertical.  One  of  the  best  known  approaches  to  direct 
vertical  linkage  of  models  is  the  the  Army's  concept  of  the  Hierarchy  of  Models. 
This  approach  reo^gnized  that  d^erent  echelons  conduct  different  functions  on 
the  battiefield  and  that  the  command  and  control  structure  is  hierarchical. 
However,  tiie  Army  Model  Improvement  Program  implemented  its  hierarchy 
using  horizontal  slices  without  standardizing  on  a  vertical  component.  With 
separate  models  imjdemented  independently  at  each  echelon,  the  command  and 
control  function  is  severed  unnaturally.  Reassembling  a  consistent  C2 
representation  is  very  difficult  to  do,  even  when  there  is  genend  agreement  before 


building  the  individual  models.  If  there  is  no  agreement,  the  task  is  nearly 
impossible. 

c.  Networited  Intr  ^*ratiop  -  H<Mizontal.  Networked  simulation  is  currently  the 
most  popular  of  the  liiwng  technologies  and  is  being  applied  at  several  different 
levels  of  entity  representation.  It  involves  creating  standard  message  protocols 
and  using  them  to  pass  needed  information  among  models  or  simvJators  at  a 
given  level  of  representation  (tinit,  platform,  module,  etc.).  At  the  platform  level 
of  representation,  SIMNET  is  the  best  example  of  networked  simuiation,  i.e.  the 
linking  of  numerous  simulators  and  simulations  (SAFOR). 

For  models  at  the  unit  level  of  representation,  the  Aggregate  Level  Simulation 
Protocol  (ALSP)  is  being  developed  by  MITRE  under  DARPA  siMnsorship  to 
address  the  shortfalls  in  the  direct  horizontal  interface  approach.  ALSP  is 
standardizing  the  information  that  must  be  be  passed  among  equivalent  level 
HOM  to  link  them.  It  is  also  building  a  generic  translator  for  messages 
containing  that  information.  This  is  a  tough  task  when  the  models  to  be 
interfaced  have  common  environments,  consistent  time  steps,  and  a  standard 
data  dictionary.  However,  most  current  HOM  have  none  of  these  and  each  model 
generally  depicts  an  independent  and  usually  different  view  of  the  environment 
and  engagements.  Currently,  a  standard  cannot  be  implemented  without 
making  mqjor  changes  to  each  of  the  linked  models.  Consequently,  the  ALSP 
program  is  significantly  modifying  both  the  AWSIM  and  CBS  models  in  the 
prototype  ALSP  implementation.  If  the  functions  of  the  additional  models  in  the 
Distributed  Waigaming  System  can  be  integrated  into  either  AWSIM  or  CBS, 
then  the  ALSP  standards  can  probably  be  generalized.  If  functions  such  as 
intelligence,  electronic  warfare,  and  deep  attack  must  continue  to  be  represented 
by  separate  models,  then  it  is  likely  that  each  existing  model  will  have  to  be 
modified  significantly  before  it  can  be  represented  on  the  network.  It  may  be  that 
building  a  new  joint  model  to  the  ALSP  standards  may  be  easier  than  making 
modifications  to  models  that  were  never  designed  to  be  interfoced. 

A  related  horizontal  networking  methodology  for  linking  HOM  is  the  Data.bus 
being  developed  at  the  Joint  Wargaming  Center  (JWC).  In  this  approach,  each 
model  is  linJked  to  a  common  network  over  which,  information  is  passed  in 
standard  formats.  This  is  an  inherently  efficient  way  to  link  models,  since  there 
is  only  one  interfiice  for  each  model.  However,  the  I)ata_bu8  does  not  provide  a 
mech^sm  or  standard  for  rationalization  or  normalization  among  the  models 
on  the  network.  Nor  does  it  have  a  way  of  dealing  with  the  large  scale  redundancy 
in  the  models  which  makes  the  normsdization  task  so  difficult.  Thus  ,  it  is  likely 
that  only  new  models  should  be  considered  for  the  Data_bus  since  migor  changes 
will  be  required  in  older  models  before  they  can  be  interfaced  to  each  other 
throui^  the  network. 

dL  Networked  Integration  •  Vertical.  Messages  can  also  be  networked 
vertically  across  echelons  as  well  as  horizontally  at  a  given  level  of  representation. 
Ususdly  t^  implementation  is  top  down.  For  example,  the  Simulated  Warfare 
Environment  (Generator  (SWEG)  model  at  the  Navy's  Air  Combat  Environment 
Test  and  Evaluation  Facility  (ACETEF)  links  vehide  and  platform  level  models 
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with  detailed  module  level  models  through  explicit  message  passing.  Keeping 
mijltiple  levels  coherent  is  a  daunting  task,  but  SWEG  handles  it  by  explicitly 
separating  the  action  or  physical  world  fnm  the  cognitive  or  mental  world 
SWEG  is  a  product  of  the  test  community  and  is  currently  applied  primarily  to  air 
defense  environments.  It  has  been  used  in  the  past  to  represent  ground  combat  at 
the  individual  vehicle  level  and  it  has  the  advantages  of  a  high  level  of 
automation,  very  efficient  software,  generation  of  real  time  3D  graphics,  and 
direct  inter&ce  with  both  man  and  ha^ware  in  the  loop.  SWEG  appears  to  have 
solved  many  of  the  problems  facing  the  direct  vertical  interface  of  a  hierarchy  of 
models  by  separating  the  physical  ground  truth  firom  the  cognitive  operations  and 
dealing  with  each  separately. 

e.  Networked  Integration  •  Hybrid.  The  Battlefield  Distributed  Simulation  - 
Developmental  (BDS-D)  is  an  Advanced  Technology  Transfer  Demonstration 
(ATTD)  program  to  achieve  and  standardize  advances  in  the  technologies  first 
demonstrate  in  the  DARPA  SIMNET  program.  Successor  BDS-D  programs  wfil 
set  up  common  environments  and  link  autonomous,  heterogeneous  simulators 
together  with  a  relatively  small  set  of  DIS  message  protocols  and  standard  data 
bases.  In  current  networked  simulation,  each  simulator  maintains  its  own  view 
of  the  world  (time  and  space  coherency  is  the  responsibility  of  the  participating 
simulator).  In  future  implementations,  BDS-D  and  other  related  programs  will 
potentially  link  across  echelons  allowing  multiple  levels  of  representation  to 
operate  in  parallel.  Each  model,  simulation,  or  simulator  would  operate  within  a 
common  environment  using  a  singd®  ground  truth,  but  each  participating  entity 
would  carry  its  own  perception  of  the  ^ttlefield  appropriate  for  its  echdon. 

£  Framework  Model  -  Hybrid.  Another  approach  to  linking  models  is  to 
utilize  a  hierarchy  of  models,  but  to  build  a  message  passing  capability  as  an 
independent  modd  which  each  echelon  in  the  hierar^y  can  use.  This  approach 
combines  the  concepts  of  hierarchy  and  family  of  models  with  an  explicit 
representation  of  command  and  control.  By  using  models  with  the  same  general 
architecture  and  coupling  them  through  their  communication  systems,  a 
common  environment  b^mes  possible.  This  makes  the  batUeboards  (depiction  of 
ground  truth)  of  each  model  common  by  agreeing  on  the  basic  parameters  of  the 
battlefield  and  a  priori  determining  rules  for  deciding  which  model  provides  the 
definitive  representation  of  particular  entities. 

This  approach  is  currently  the  architecture  being  pursued  at  the  SDIO 
National  Test  Bed  (NTB).  It  is  particularly  useful  if  the  resulting  model  is  able  to 
make  a  distinction  between  ground  truth  and  perceptions  and  passes  separate 
messages  for  each  (with  only  the  cognitive  ones  accessible  by  the  decision  making 
elements  of  the  participating  entities.  The  METRIC  and  ACES  models,  currently 
being  used  by  the  Aiiny  Command  and  General  Staff  School  and  the  USAF 
Wargaming  Center,  respectively  are  terrestrial  examples  of  framework  models  in 
whi(h  more  detailed  representations  of  various  entities  can  be  embedded. 


g.  Parallel  Prooessiiig.  There  are  at  least  two  simulation  projects  employing 
parallel  processing  whose  products  have  potential  application  to  wargaming.  The 
first  is  the  Concurrent  Theater  Level  Simulation  (CTLS)  being  devdoped  by  the 
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Army  Concepts  Analysis  Agency  (CAA).  The  second  is  the  Rome  Air 
Devdopment  Ccmter's  Dynamic  Ground  Target  Simulator  (DOTS).  Both  models 
are  experiments  at  producing  much  higher  fidelity  simulators  than  are  currently 
available  by  emplojdng  the  computer  power  available  on  large  scale  parallel 
processing  computers.  Neither  model  currently  has  a  man  in  the  loop  version 
which  could  support  this  effort 

h.  Encapsulation.  Encapsulation  is  a  technique  for  nonintrusive  control  of  an 
existing  simulation.  An  external  firamework  is  u^  to  preprocess  all  inputs  and 
postprocess  all  outputs  of  the  model  in  question.  This  avoids  problems  with 
potentially  invalidating  a  simulation  by  changing  portions  of  its  internal 
operations  or  capabilities.  Currently,  PM  TRADE  is  sponsoring  an  effort  to 
enhance  the  BBS  model  and  reduce  some  of  the  manpower  required  to  run  it  by 
encapsulating  BBS  with  a  program  called  STAFCA.  ^  an  unrelated  effort,  Booz- 
AUen  Hamiliton  (BAH)  and  Coleman  Researdi  are  currently  joined  in  a  effort  to 
encapsulate  several  modds  and  use  the  encapsulation  process  as  the  translator 
in  a  linking  approach. 

Summaiy  of  the  Linking  Options.  The  IHOM  task  does  not  have  the  resources 
and  shoiild  not  attempt  to  duplicate  linking  approaches  currently  being 
implemented  by  the  ALSP  program,  the  JWC  Data.bus,  the  EAGLE-SIMNET 
linkage  or  any  of  several  related  programs  .  It  is  becoming  increasingly  obvious 
that  most  large  scale  models  at  the  corps  or  theater  level  of  operation  require 
almost  as  mu^  effort  to  collectively  mod^  as  would  be  required  to  adopt  a  new 
approach  with  a  common  environment  and  an  explicit  message  passing 
architecture.  However,  such  an  approach  could  not  be  considered  if  ff  it  has  not 
been  successfully  demonstrated.  The  IHOM  challenge,  therefore,  is  to  identify 
existing  models  which  meet  the  BDS-D  criteria  for  intmfiicing,  i.e.  object  oriented, 
message  passing,  etc;  pick  at  least  one  such  higher  order  mo^l  (preferably  a  joint 
model),  and  interface  it  in  real  time  with  a  DIS  compliant  vehicle  level 
simulation.  The  best  way  to  do  this  appears  to  be  a  combination  of  several  linking 
technologies.  For  example,  using  a  firamework  model  to  encapsulate  a  detailed 
platform  level  simulation  which  1^  the  capability  to  link  upwards. 

2,5  Becommedatiaiis 

2JS.1  General 

The  functions  available  firom  higher  order  models  that  would  most  benefit 
BDS-D  realism  involve  weapon  and  sensor  systems  that  could  affect  the  battalion 
area  and  the  command  and  control  functions  that  would  coordinate  these 
interactions.  Higher  level  weapons  include  long  range  artillery  such  as  the 
Russian  D-30,  si^ace  to  surface  missile  systems  su(^  as  the  Army  Tactical 
Missile  System  (ATACMS)  and  the  Russian  ^UD,  attack  helicopters,  fixed  wing 
aircraft  involved  in  Battlefidd  Air  Interdiction  (BAI)  as  well  as  Qose  Air  Support 
(CAS),  and  Naval  gunfire.  Higher  level  sensors  include  both  Army  controlled 
systems  such  as  the  Guardrail  and  Quicklook  aircraft,  the  USAF  JSTARS,  and 
foreign  equivalents  of  these  systems. 
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Based  on  the  evaluation  of  higher  order  models,  four  higher  order  models 
appear  to  have  the  necessary  functions  implemented  in  an  object  oriented 
manner,  SWEG  at  the  vehicle  level  of  representation,  COBBAN  and  EAGLE  at  the 
corps  level,  and  METRIC  at  the  theater  levd.  Of  these,  SWEG,  COBBAN  and 
METRIC  operate  on  a  desktop  workstation  (SUN™)  and  are  immediately 
available  from  Government  sources.  Eagle  has  an  extensive  array  of  additional 
capabilities,  especially  in  the  C3I  area,  but  the  model  is  not  scheduled  to  be 
available  until  it  has  completed  testing  its  interface  with  SIMNET,  approximately 
the  end  of  1992. 

The  mOM  recommendation  is  to  start  slowly  using  the  minimum  number 
of  models  to  accomplish  the  purpose.  Therefore  it  is  planned  to  use  the  METRIC 
theater  level  simulation  to  create  a  large  scale  enviroiunent  encapsulating  the 
SWEG  model  (which  would  be  used  to  approximate  a  BDS-D  model  for  the 
purposes  of  this  efifort).  METRIC  would  generate  both  unit  objects  and  specific 
individual  entity  objects.  These  will  provide  the  context  for  BDS-D  including  the 
provision  of  corps  and  division  weapon  and  sensor  systems.  Based  on  the  success 
of  this  vertical  linkage,  the  Army  model  EAGLE  or  the  seminar  wargame 
CORBAN  would  be  examined  for  additional  detailed  functions,  especially 
command  and  control  decision  making.  The  METRIC  model  is  a  sister  model  to 
both  SWEG  and  CORBAN.  Since  they  use  essentially  the  same  message  passing 
software  architecture,  it  is  anticipated  that  linking  them  vertically  will  not 
encounter  the  problems  faced  by  the  model  hierarchy  developed  for  the  Army 
Model  Improvement  Program.  That  is  not  to  say  Uiat  problems  will  not  be 
encountered,  but  the  use  of  a  conunon  architecture  is  a  powerful  support. 

2.6  Proposed  2  Deliveiy  Order  For  Int^ration  of  Killer  Order 

Models  (HOM)  into  the  BDS-D  Ehivironment. 

2.7  Background. 

In  the  Step  1  IHOM  Task,  it  was  determined  that  integration  of  BDS-D  with 
higher  order  models  would  provide  several  benefits.  Foremost  among  these  is  the 
command  and  control  context  for  velude  level  BDS-D  battalions  and  the  provision 
of  functions  which  BDS-D  does  not  currently  provide  automatically  such  as  higher 
level  fire  support  and  intelligence.  Since  Army  doctrine  would  not  normally 
commit  a  batt^on  to  combat  without  the  availability  of  such  assets,  it  is  essentisd 
to  add  them  to  BDS-D  to  create  a  realistic  battlefield  environment.  This  Step  2 
Delivery  Order  describes  research  to  demonstrate  that  the  concept  of  integrating  a 
BDS-D  like  model  with  a  selected  higher  order  model  (HOM)  is  feasible  for  a  very 
reasonable  level  of  effort  Gess  than  two  staff  years).  It  provides  an  easy  and 
relatively  inexpensive  path  to  allow  BDS-D  to  operate  within  a  far  more  realistic 
battlefield  as  it  expands  its  capabilities. 
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2^  Approeda» 

2^1  General  Overview 

The  Step  1  Task  determined  that  several  object  oriented,  higher  order  models 
(HOM)  existed  such  as  METRIC,  EAGLE,  and  CORBAN  wluch  could  potentially 
create  a  compatible  combat  environment  in  which  BDS-D  could  be  embedded. 
Furthermore,  this  could  be  done  without  extensive  changes  to  either  the 
aggregated  HOM  or  BDS-D.  The  initial  concept  was  to  run  an  object  oriented 
higher  order  model  such  as  the  METRIC  theater  level  model  along  with  the  the 
EAGLE  or  CORBAN  corps  level  model  in  parallel  with  a  model  such  as  the 
Simulated  Wsurfare  Environment  Generator  (SWEG)  which  would  represent  the 
vehicle  level  BDS-D  model.  After  further  examination,  it  was  determined  that 
simply  interfacing  the  theater  level  model  would  be  sufficient  if  it  provided  a  low 
enough  echelon  such  as  battalion  with  which  to  interface. 

The  models  would  be  loosely  coupled  by  a  simulated  command  and  control 
system  for  passing  orders,  delivering  sensor  messages,  and  making  request  for 
fire  support  and  logistics.  Internal  to  the  models  and  transparent  to  the 
participants,  special  purpose  messages  would  also  be  sent  to  tightly  couple 
ground  truth  in  each  of  the  models.  BDS-D  manned  or  simulated  (computer 
generated  forces)  vehicles  would  simply  become  more  detailed  versions  of  selected 
unit  objects  within  the  higher  order  model  and  would  assume  reporting 
responsibility  for  them,  both  for  explicit  command  and  control  and  for  \mderlying 
ground  truth. 

Elements  from  echelons  represented  in  the  higher  order  model  (METRIC),  but 
not  in  BDS-D,  such  as  resupply  convoys,  replacements,  arriving  aircraft,  long 
range  artillery,  etc  would  enter  the  surrogate  BDS-D  model  (SWEG)  from  the 
HOM  as  transition  objects  for  which  SWEG  then  assumes  local  responsibility  for 
both  reporting  and  ground  truth.  In  this  short  term  effort,  all  unit  objects  outside 
the  BDS-D  battalion  area  of  interest  not  already  represented  as  individual 
platforms  would  remain  in  their  aggregated  form.  However,  small  cells  of  high 
fidelity  could  be  created  at  any  point  within  the  higher  order  model  to  observe 
specific  vehicle  level  interactions  such  as  raids.  In  later  efforts,  whole  battalions 
could  potentially  be  deaggregated  as  needed  to  interface  with  the  vehicle  level 
simulation. 

2.1.1  Interactions.  Since  the  purpose  of  this  effort  is  to  provide  a  larger 
battlefield  context  for  BDS-D,  aU  interaction  between  the  HOM  and  the  BD&D 
model  will  be  at  the  platform  or  vehicle  level  with  interacting  elements  fimm  the 
HOM  being  deaggregated  as  needed  to  provide  the  necessary  interaction.  No 
direct  interaction  is  planned  between  aggregated  objects  and  platform  level 
entities.  The  higher  order  model  would  be  commanded  by  a  BLUEFOR  and  an 
ORANGEFOR  commander  who  receive  detailed  updates  on  the  battlefield  through 
the  higher  level  model's  sensors  and  communications  network.  These  would  be 
joint  commanders  with  air  and  land  component  commanders  supporting  either 
in  person  or  as  computer  generated  forces.  If  desired,  a  naval  component  could 
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be  included  as  the  METRIC  joint  simulation  plays  all  Service  resources  within  a 
common  environment. 


The  land,  air,  and  naval  component  commanders  would  direct  their 
operations  using  the  platform  and  aggregated  level  objects  available  in  the  theater 
and  corps  level  simulation,  e.g.  aircraft,  airbases,  ships,  ports,  etc.  and 
interacting  with  opposing  brigades,  regiments,  divisions,  etc.  as  part  of  the 
METRIC  simulation.  As  they  enter  certain  geographic  areas,  they  interact 
directly  with  tiie  SWEG  model  (representing  a  BD&D  surrogate).  These  objects 
would  continue  to  respond  to  their  original  orders  or  flight  path,  but  SWEG  would 
assiime  responsibility  for  interactions  with  both  the  local  forces  and  the  local 
environment.  When  vehicles  depart  the  area  controlled  by  SWEG,  it  passes  a 
message  to  the  HOM  scoreboard  restoring  the  original  status  of  the  objects  and 
restoring  control  of  them  to  the  HOM.  The  transition  point  is  basically  the 
boundary  at  which  Distributed  Interactive  Simulation  (DIS)  messages  start  to  be 
generated  (ingress)  or  stop  being  generated  (egress).  For  objects  such  as 
ATACMS  or  downed  aircraft  which  terminate  in  ^e  BDS-D  area,  SWEG  would 
report  on  the  outcome  of  the  engagement  and  pass  messages  to  its  own  scoreboard 
and  the  scoreboard  of  the  HOM. 

2.1.2  Human  Interaction.  It  is  anticipated  that  both  the  air  and  naval  forces 
would  operate  primarily  on  sets  of  orders  input  at  the  start  of  the  scenario  to 
reduce  ^e  complexity  of  tracking  results.  Changes  in  operations  would  occur 
automatically  as  the  forces  interacted  and  additional  clusu^es  could  be  input  to 
demonstrate  that  the  forces  are,  in  fact,  under  control  and  not  scripted.  The  land 
forces  component  commander,  on  the  other  hand,  would  have  botii  theater  level 
assets  and  corps  level  assets  to  direct.  Using  the  concept  of  a  semi-autonomous 
corps  operating  as  part  of  a  joint  task  force  in  a  theater  of  operations,  a  slice  of  one 
or  more  corps  covdd  be  represented  in  more  detail  using  a  detailed  corps  level 
model  embedded  in  the  theater  level  model.  Those  elements  outside  the  detailed 
corps  are  portrayed  by  the  common  theater  environment  down  to  brigade  or 
regimental  level.  The  corps  level  model  would  be  played  at  the  battalion  level,  but 
displayed  to  the  senior  command  level  at  the  brigade  level  to  avoid  indicating 
where  the  additional  level  of  detail  was  being  applied.  Within  the  co^s  level 
model,  one  battalion  would  be  designated  to  be  represented  by  BDS-D  vehicle  level 
Computer  Generated  Forces.  Figure  12.4-1  shows  the  overall  concept  of 
encapsulating  smaller  models  within  larger. 
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Figure  12.4-1  The  Hi|^ier  Order  BfoddeEncwpewlate  the  Lower  LeiwelModde 


Becatise  the  METRIC  higher  order  model  being  used  is  object  oriented  and  is 
not  broken  into  large  sectors,  it  is  not  tied  to  PLOT  movement  (as  in  TACWAR)  or 
to  maintaining  strict  limitations  on  one  side  or  the  other  controlling  specific 
terrain  (as  in  the  CBS  model).  Therefore,  the  opportunity  exists  to  also  conduct 
relatively  small,  but  highly  visible  deep  operations  with  airborne  or  air  assault 
forces.  This  would  be  done  initially  within  the  context  of  the  theater  simulation. 
However,  in  future  efforts,  it  could  be  interfaced  with  either  the  existing 
simulators  at  Ft.  Rucker  or  with  the  Rotaiy  Mfinged  Aircrafii  (RWA)  initiative. 

2.&2  Specifics 

2.8.2.1  Theater  Level.  There  is  presently,  only  one  theater  level  model  in  use 
within  the  Army  which  has  demonstrated  fbll  theater  scope,  joint  operations  at 
the  object  level,  man  in  the  loop  capability,  and  runs  in  real  time.  This  is  the 
METRIC  model  in  use  at  the  Command  and  General  Staff  School.  Another 
feature  of  the  METRIC  model  is  that  it  operates  on  a  desktop  workstation  which 
makes  it  relatively  easy  to  use. 

The  METRIC  higher  order  model  was  recently  iised  to  examine  Deep  Attack 
options  on  a  multi>corps  batUefield  and  is  now  being  used  to  examine  Anny  Deep 
Operations  at  Echelons  .Above  Corps  (EAC).  Efforts  are  also  under  way  to  employ 
h^TRIC  at  the  Command  and  General  Staff  School  at  Ft.  Leavenworth  as  a 
prototype  model  to  examine  the  feasibility  of  supporting  training  in  joint  plannii^ 
and  operations.  METRIC  uses  an  architecture  that  has  been  implemented  in 
several  other  models  both  at  the  theater  level  and  at  more  detailed  levels  down  to 
and  including  continuous  view  vehicle  level  models.  Related  models  at  the 
theater  level  indude  F(^US  at  the  Office  of  Net  Assessment  in  OSD  and  the  Air 
Combat  Exerdse  System  (ACES)  at  the  USAF  Wargaming  Center. 
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2.8^^  Corps  LeveL  The  concept  of  integrating  th6  METRIC  joint  model  with  a 
detailed  corps  level  model  is  very  similar  to  one  being  discussed  at  the  Army 
Command  and  General  Staff  School.  However,  at  Leavenworth,  the  student  body 
and  the  Battle  Command  Training  Program  (BCTP)  provide  large  numbers  of 
both  warfighters  and  support  personnel  and  allow  the  use  of  the  Corps  Battle 
Simulation  (CBS)  as  the  coips  level  model. 

Large  numbers  of  support  personnel  will  not  be  available  to  conduct  corps  level 
operations  for  this  effort.  Consequently,  CBS  is  not  considered  to  be  a  good 
candidate  for  this  effort.  EAGLE  scored  by  fiir  highest  in  the  Step  1  tech^cal 
evaluation  of  corps  level  models,  but  it  is  not  presently  available.  Furthermore, 
the  team  proposed  for  this  effort  has  had  no  opportunity  to  work  with  the  model. 
As  both  of  these  conditions  change,  EAGLE  will  become  the  candidate  of  choice  for 
a  corps  level  model  to  link  to  BDS-D. 

The  next  highest  scorer  in  the  evaluation  was  the  Corps  Battle  Analyzer 
(CORBAN).  It  is  presently  designated  as  a  Seminar  Training  tool,  but  is 
primarily  being  used  as  an  analytical  tool  at  Army  Concepts  Analysis  Agency. 
While  CORBAN  is  not  being  used  as  a  man  in  the  loop  model,  it  is  closely  related 
to  CORDIVEM,  ICOR,  CIJBW,  and  other  Army  models  which  have  been  used 
with  man  in  the  loop.  It  is  currently  configured  to  operate  in  a  batch  mode,  but  an 
interactive  mode  is  available. 

Since  CORBAN  uses  the  same  architecture  as  the  METRIC  model,  the  current 
thought  is  to  consider  CORBAN  components  as  possible  additions  to  the  METRIC 
model,  but  to  simply  go  from  theater  to  battalion  level  and  reduce  the  complexity  of 
the  effort  by  utilizi^  only  two  models  METRIC  and  SWEG).  Since  the  focus  is  on 
what  can  be  done  to  enhance  the  environment  and  capabilities  of  the  BDS-D  level 
model,  the  source  of  the  information  makes  little  difference. 

2.8.2.3  Battalion  Level.  For  one  of  the  battalions  in  the  corps  level  simulation 
and  for  the  enemy  regimental  units  opposing  it,  the  corps  level  algorithms  wiU  be 
replaced  by  input  from  SWEG  computer  generated  forces  operating  at  the  vehide 
level  of  resolution  on  detailed  terrain.  Up^tes  within  the  SWEG  model  will  be  at 
a  rate  and  in  a  format  compliant  with  the  Distributed  Interactive  Simulation 
(DIS)  standards.  The  interface  with  the  METRIC  model  or  the  CORBAN  model 
should  be  relatively  straightforward  since  the  all  use  a  similar  data  driven 
approach  and  a  common  architecture  that  inherently  separates  physical  actions 
and  cognitive  operations. 

When  unit  sized  elements  such  as  battalion  or  regiments  interact  within 
SWEG,  it  will  be  done  at  the  vehide  or  platform  level  with  updates  occurring  on 
the  order  of  several  times  a  second.  In  keeping  with  the  BDS-D  objective  of 
expanding  the  battlefield,  this  effort  will  focus  on  adding  new  capabilities  rather 
than  portraying  large  numbers  of  armored  vehicles  which  has  already  been 
demonstrated^  SWEG  assumes  the  responsibility  for  generating  the  necessary 
messages  to  establish  and  maintain  objects  receiv^  firom  the  HOM  on  the  virtuid 
network.  For  the  purposes  of  this  effort,  it  is  likely  that  the  virtual  network  will  be 
simulated  by  s^red  memory  to  reduce  the  complexity  of  the  interface  task. 
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SWEG  will  also  be  responsible  for  maintaining  communications  with  the  highOT 
level  models  for  all  objects  under  its  control  even  thou|^  the  BDS-D  battalion  will 
not  be  directly  involv^.  The  higher  or^r  model  has  no  responsibility  for  objects 
within  the  SV^G  area  of  control  and  no  direct  interaction  with  any  objects  under 
SWEG  control.  However,  the  HOM  will  still  have  its  scoreboard  up^t^  regularly 
or  for  for  events  which  it  recognizes.  This  allows  higher  level  interactions  to 
occur  (such  as  long  range  radar  tracking)  outside  of  the  BDS-D  environment. 

To  keep  the  problem  of  seams  under  control  and  focus  on  vertical  integration, 
this  Step  2  effort  wUl  keep  most  HOM  units  separated  from  the  detailed  model 
units  at  distances  that  limit  direct  visual  interaction.  Results  of  battles  at  the 
platform  level  will  be  reported  upward  in  messages  along  with  requests  for 
support.  These  will  pass  through  the  various  levels  of  the  hierarchical  command 
and  structure  as  they  are  represented  in  the  corps  and  theater  level  models  and 
will  be  available  at  every  echelon.  At  appropriate  levels  they  will  be  aggregated  to 
more  closely  approximate  actual  status  reports. 

The  level  of  controller  and  map  display  associated  with  the  IHOM 
demonstration  is  dependent  on  the  success  of  Ta^  1  of  the  BDS-D  Step  2  Delivery 
order  which  is  developing  an  advanced  interface  to  the  SWEG  software  as  part  of 
the  Computer  Generated  Forces  task.  Given  that  the  demonstration  of  the  IHOM 
interface  is  successfrd,  in  the  next  step,  manned  vehicles  would  participate  in 
coqjunction  with  the  CGF.  There  will  continue  to  be  no  direct  interaction  l^tween 
SWEG  and  the  higher  order  models  at  different  levels  of  aggregation.  The  focus  of 
this  and  related  efforts  is  to  expand  the  number  and  types  of  vehide  level 
interactions  that  can  occur  on  the  man  in  the  loop,  real  time  tettlefield. 

2.&2.4.  Vehicle  Level.  The  tank  battalion  at  the  Knox  SIMNET  -T  site  and  the 
helicopters  simulators  at  the  Ft.  Rudcer  site  are  the  primary  candidates  for 
conducting  the  next  version  of  this  effort  involving  distributed  manned 
simulators.  Such  an  interface  would  be  stretching  the  state  of  the  art  for  the  level 
of  effort  and  the  timeframe  proposed  here  and  is  not  recommended  for  indusion 
in  this  first  Step  2  IHOM  effort.  This  effort  focuses  on  demonstrating  a  coherent 
hierarchical  environment  in  which  objects  and  messages  are  passed  ^m  level  to 
level.  At  the  successful  condusion  of  this  effort,  with  the  confirmation  that  the 
transfer  is  occurring  smoothly  between  levels  and  the  DIS  protocol  data  units  are 
being  properly  generated  and  interpreted  a  follow-on  should  be  conducted  to 
demonstrate  manned  vehide  in  the  loop.  This  assumes  that  within  a  year  either 
DIS  compliant  manned  vehide  simulators  will  be  available,  or  a  translator  will  be 
available  to  convert  firom  DIS  to  SIMNET  protocols. 

2,9  Summary 

There  are  large  numbers  of  higher  order  models  and  simulations  with  which 
BDS-D  could  potentially  be  interfaced  to  enhance  its  capability  and  promote  a 
rapid  expansion  of  its  scope.  However,  most  of  these  models  do  not  have  the 
attributes  which  would  xnake  this  interface  a  straightforward  process.  The 
evaluation  described  above  looked  at  a  subset  of  higher  order  models  that  each  had 


March  31,  UMS 


51 


ADST/WDI/m-83-OOSOlO 


%— UJi 

at  least  some  of  the  characteristics  that  satisfied  the  technical  evaluation  criteria. 
It  was  determined  early  that  modds  at  essentiaUy  the  same  level  as  BDS-D  should 
not  be  further  considered  as  they  broui^t  few  new  functions  to  BDS-D  and  would 
be  difficult  to  interface  without  significant  changes.  The  remaining  higher 
echelon  models  (above  battalion)  were  grouped  into  two  sets.  Those  that  were 
echelons  corps  and  below  and  those  that  were  joint  models  and  included  echelons 
above  corps.  Each  was  evaluated  separately  with  the  idea  of  working  vertically  in 
two  steps,  i.e.  first  to  corps  and  then  to  theater.  This  was  determined  not  to  be 
necessary  if  one  joint  model  could  span  the  hierarchy  from  theater  to  battalion. 
The  METRIC  model  was  identified  as  providing  that  capability  and  scored  highest 
of  the  theater  level  HOM  on  the  criteria  evaluation.  It  is  dear  that  object  oriented 
models  do  exist  at  every  level  of  the  command  hierarchy,  but  that  they  have  not 
been  used  to  create  an  environment  for  more  detailed  object  oriented  models  such 
as  BDS-D.  Consequently  this  study  recommends  that  the  Step  2  Delivery  Order 
described  above  be  implemented  to  demonstrate  the  feasibility  of  integrating 
BDS-D  models  with  higher  order  models  to  the  benefit  of  both. 

It  is  antidpated  that  once  the  proof  of  concept  of  interfadng  DIS  compliant 
BDS-D  vehide  level  models  to  higher  order  models  has  been  demonstrated 
internal  to  the  ADST  program,  the  next  step  would  be  a  full  demonstration 
involving  commanders,  st^dfs,  and  platform  crews  at  the  multiple  levels  being 
represented.  Since  the  involvement  of  senior  commanders  and  the  commitment 
of  large  numbers  of  troops  and  simulators  is  a  m^jor  endeavor,  the  IHOM  task 
focuses  on  demonstrating  the  feasibility  of  integrating  SWEG  (as  the  BDS-D 
surrogate)  with  higher  order  models  in  a  near  seamless  manner  rather  than 
generating  large  numbers  of  vehides.  Upon  successful  demonstration  of  this 
integration,  there  is  a  natural  progression  to  the  detailed  real  time  simulation  of  a 
total  theater. 

Thus  at  some  time  in  the  future,  it  will  be  possible  to  represent  the  entire 
theater  at  the  vehide  level  of  resolution.  However,  in  the  meantime,  higher  order 
models  can  encapsulate  BDS-D  platform  level  models  such  as  SWEG,  creating 
zones  of  high  detail  within  the  low  resolution  higher  order  model.  At  the  same 
time  BDS-D  benefits  from  the  richness  of  the  battlefield  context  created  by  the 
higher  order  object  oriented  model.  It  is  highly  recommended  that  such  a 
demonstration  be  conducted. 
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3.  OljectOrieiitedDefiigaafDlS 

An  argument  is  presented  for  designing  the  DLS  system  in  an  object-oriented 
fashion.  Five  attributes  of  the  DIS  Architecture  effort  strongly  imply  that  an 
object-oriented  approach  to  its  design  and  implementation  is  necessary.  These  are 
distribution,  heterogeneity,  reusability,  reconfiguration,  and  complexity,  and 
their  implications  for  DIS  are  ^scussed.  The  sof^are  implementation  problems 
of  attempting  a  fully  object-oriented  design  in  Ada  are  discussed  and  the  use  of 
object-orient^  GOTO  extensions  to  Ada  is  recommended.  Finally  the  issues  of  a 
distributed  object-oriented  system  are  examined,  and  the  efforts  of  the  commercial 
industry  standards  group  OMG  (Object  Management  Group)  to  deal  with  these 
issues  are  discussed.  Cooperation  between  the  DIS  community  and  the  OMG  is 
recommended. 

3.1  Overview  oftlieOfcgect  Model  and  its  Relevance  to  DIS 

Five  attributes  of  the  DIS  Architecture  effort  strongly  imply  that  an  object- 
oriented  approach  to  its  design  and  implementation  is  necessary: 

•  Distribution.  The  DIS  Architecture  calls  for  a  distributed  system  whose 
elements  are  provided  by  different  vendors.  The  message  passing 
between  objects  paradigm  of  object-oriented  approaches  supports  the 
distributed  nature  of  DIS. 

•  Heterogeneity.  The  elements  of  the  DIS  Architecture  are  heterogeneous 
in  application  and  implementation  (e.g.  manned  vehicle  simulators, 
Computer-Generated  Forces  veludes  and  Units,  ag^egate  wargames, 
operational  equipment).  It  is  not  feasible  to  dictate  a  unifying 
implementation  on  the  elements.  Thus  data  abstraction  and 
encapsulation  are  methods  by  which  the  heterogeneity  of 
implementation  for  similar  or  same  functions  can  be  supported. 

•  Reusability.  The  DIS  Architecture  calls  for  the  integration  of  extant 
systems,  some  of  which  may  not  have  been  initially  designed  for  the  DIS. 

In  order  to  avoid  endless  and  hence  expensive  pairwise  integration, 
general  interfaces  will  be  needed  to  interpret  ^tween  the  internal 
requirements  of  the  system  and  the  DIS  Protocols.  Object  wrappers 
provide  a  feasible  approach  to  this  problem  [Soley,  1990;  OMG,  1991b]. 

•  Reconfiguration.  The  DIS  architecture  calls  for  easy  and  rapid 
reconfiguration  of  simulation  entities  to  create  sessions  with  new 
comlnnations  of  entities  and  to  create  entities  with  new  combinations  of 
behaviors  and  parts.  The  object  model  provides  a  level  of  control  and 
management  over  this  process  not  provided  by  functional  methods. 

•  Complexity.  The  warfighter-in-the-loop,  coupled  to  the  scale  and  scope  of 
the  goals,  will  drive  the  DIS  system  to  arbitrary  levels  of  complexity. 
Object-oriented  design  and  implementation  has  been  developed  to  deal 
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with  the  problems  created  by  modem  complex  software  systems  that  the 
functioiial  methods  are  inadequate  to  deal  with. 

It  is  worth  reviewing  what  is,  and  what  is  not,  an  object-oriented  approach.  An 
object-oriented  approa<£  has  thrM  attributes  [Booch,  IS^l]: 

•  Objects.  Uses  objects  not  algorithms  (functions)  as  its  fundamental 
blinding  blodu.  Objects  are  data  abstractions  with  an  inter&ce  of  named 
operations  and  a  hidden  local  state. 

•  Class  Structure.  Objects  are  instances  of  dasses. 

•  Inheritance.  Objects  are  related  to  each  other  via  type-of  inheritance, 
they  inherit  attributes  from  their  superdasses. 

If  any  of  these  elements  are  missing,  then  the  approach  is  not  object-oriented. 
It  may,  however,  be  object-based  (as  is  Ada,  which  lacks  multiple  in^ritance  and 
polymorphism)  dealing  with  abstract  data  t^^s  instead  of  objects). 

The  Object  Model  has  seven  elements.  Four  of  these  are  migor  (if  any  one  of 
these  are  missing  then  the  approach  is  not  object-oriented),  and  tlu^  are  minor 
(usefril  but  not  essential)  (see  ^gure  1). 


Elements  of  the  Object  Model 


Major  Elements 

Minor  Elements 

Abstraction 

Typing 

Encapsulation 

Concurrency 

Modularity 

Persistence 

Hierarchy 

Figure  1:  Ffcanenteofflie  Object  BiodelDirBody  Support  ModeniSoliwiirBFngiiMwHng 
Practices.  There  are  seven  elements  of  the  object  model,  four  of  which  are  critical  if  an 
approach  is  to  be  object-oriented  and  three  of  which  are  valuable  [Booch,  1991]. 


3J2  ApplyiiigOliject  Model  Elements  to  DIS 
3.2.1  Abstractiioa 

Abstraction  concentrates  on  the  essential  characteristics  of  an  object  that 
distinguish  it  from  all  other  kinds  of  objects.  Choice  of  abstraction  is  thus 
dependent  on  a  choice  of  which  characteristics  are  important,  and  thus  many 
different  levels  of  abstraction  are  possible.  Abstraction  provides  dean  interfaces 
between  objects,  and  separates  the  object  concepts  from  any  implementation 
choices.  [Bo^,  1991]. 


The  DIS  Architecture  will  contain  many  instances  of  objects  of  the  same  type 
(e.g.  Ml  manned  simulators)  but  which  are  manufactured  by  different  vendors 
and  thus  implemented  in  possibly  very  different  ways.  However,  each  Ml 
simulator  should  behave  in  a  manner  consistent  with  that  defined  for  the  Ml 
object.  Additionally,  many  instances  wUl  occur  of  objects  of  similar  t^es  (e.g. 
different  types  of  tank  suc^  as  T-72  and  Ml),  and  these  types  will  contain  similar 
behaviors,  resulting  in  the  possibility  of  sharing  large  quantities  of  code  and 
design  effort  between  the  different  objects.  Thus  abstraction  is  a  mechanism  for 
building  the  taxonomy  of  objects  with  their  behaviors  in  the  DIS  world,  and 
providing  a  plan  to  wMch  the  various  implementors  can  adhere. 

3.2^  Encapsulatian 

Complementary  to  abstraction  is  encapsulation.  Abstraction  concentrates  on 
the  externals  of  the  object,  encapsulation  hides  the  internal  implementation 
decisions  fi:nm  all  other  external  objects.  Encapsulation  provides  explicit  barriers 
among  different  alMtractions,  and  implements  the  concept  of  data  hiding.  [Booch, 
1991]. 

The  DIS  Architecture  will  contain  a  vast  number  of  differently  implemented 
systems.  Maintainability  issues  alone  demand  that  modifications  to  one  part  of 
the  system  not  require  modifications  to  the  implementation  of  other  parts  of  the 
system  if  at  all  possible.  Encapsulation  provides  a  mechanism  for  handling 
separate  and  independent  implementation  and  development  of  the  interacting 
systems  in  the  DIS  environment. 

3.2.3  Modularity 

Modularity  is  the  property  of  a  system  that  has  been  partitioned  into  groups  of 
abstractions  with  well  defin^  inteifaces  between  these  groups.  These  groups  and 
their  interfaces  provide  a  mechanism  for  understanding  both  the  complexity  of 
the  program  and  the  real  world  it  models  by  a  divide  and  conquer  approach.  As 
with  abstraction,  many  possible  partitioning  decisions  can  be  made  depending  on 
the  viewpoint  of  the  user  or  designer.  [Booch,  1991]. 

The  DIS  environment  will  contain  many  groups  of  objects  (vehicles) 
corresponding  to  Battlefield  Functional  Areas  (BFA),  or  groups  of  unit  bdonging 
to  types  of  superior  unit,  for  example.  Modularity  will  assist  in  the  design  effort 
associated  with  partitioning  the  battlefield  domain  into  manageable  chun^. 

3.2.4  ffierarcliy 

This  is  arguably  the  most  important  element  of  the  object  model.  In  complex 
domains  there  will  be  more  different  abstractions  than  can  be  comprehended  at 
one  time.  Encapsulation  will  help  manage  this  complexity  by  hidi^  the  inside 
view  of  the  abstractions.  Modularity  will  assist  by  clustering  logical  groups  of 
object.  However,  these  concepts  are  insufficient,  and  in  a  complex  domain  the 
abstractions  will  form  hierardues.  Identification  of  these  hierar^es  will  greatly 
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aimplify  imderstanding  of  the  domain.  The  two  most  important  hierarchies  in  a 
complex  domain  are  its  class  structure  and  its  aggregation  structure 

(part-of).  In  addition,  it  is  possible  to  have  association  structures,  where  objects 
are  associated  with  each  other  even  thous^  they  are  not  parts  of  each  other  or 
types  of  each  other.  Furthermore,  in  complex  ^mains  the  hierarchies  will  be 
multiple-inheritance  rather  than  single  inheritance.  This  means  that  an 
abstraction  may  inherit  attributes  firom  more  than  one  class  strut  ..;re.  [Booch, 
1991]. 

In  DIS  for  example,  a  manned  Ml  simulator  will  inherit  from  the  manned 
simulator  abstraction  as  well  as  from  the  tank  abstraction,  while  a  computer¬ 
generated  forces  tank  will  inherit  from  the  computer-driven  simulator 
abstraction  and  the  same  tank  abstraction  as  the  manned  Ml  simulator. 

The  full  type-of  hierarchy  for  the  DIS  Architecture  will  form  a  taxonomy  of 
objects,  and  will  provide  two  central  services  to  the  DIS  Architecture.  First,  it  wBl 
provide  a  template  to  plan  implementation  of  individual  systems,  select  extant 
systems  for  integration,  and  guide  the  design  of  object  wrappers  around  extant 
systems.  Second  it  will  provide  data  input  to  a  knowledge  base  for  reasoning  about 
the  domain.  This  second  service  is  vital,  it  provides  the  core  knowledge  about  the 
synthetic  environment  known  as  DIS  to  all  its  participants,  and  most  especially  to 
computer-generated  forces  decision  making  c^.  This  permits  each  participant 
to  make  reasonable  assumptions  about  how  the  other  participants  reason,  and 
thus  behave  intelligently  without  haying  to  explain  every  last  detail  about  every 
situation.  For  example,  with  the  hierarchy  available  a  situation  map  object 
(belonging  to  a  computer-generated  force)  could  be  asked  for  the  number  of  tanks 
in  an  area,  and  the  type-of  hierarchy  asked  for  the  number-of-tanks  attribute  of 
each  echelon  of  unit,  thus  providing  the  military  intelligence  function  of 
aggregating  reports  of  numbers  of  veMdes  into  what  size  unit  is  present  (see 
Figure  2). 
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Figure!:  XlieOliijaok  Model  Hienrehyus  a  Kauwledgu  Base.  Hie  DISOlgeetBfodel 

Hierarchy  is  also  a  knowledge  etnietore  amulable  fin*  reasoning  by  qrstems  within  the 
DIS  oivironmenL  For  example,  an  intelligence  BOS  olgeet  (belonging  to  a  computer* 
generated  forces  unit)  could  ask  a  terrain  object  for  the  number  of  tanks  in  a  spedfic  area. 
Ike  terrain  object  would  pass  this  back,  and  the  intelligenoe  BOS  object  could  Aen  aA  the 
organisation  object  for  command  levels  consistent  with  this  number.  Eadi  of  these  objects 
is  inherited  fay  qwcific  objects  in  the  DIS  simulatioo  eystem. 


A  type-of  taxonomy  of  objects  is  required  for  DIS.  A  core  taxonomy  must  be 
agreed  on,  and  then  extended  and  modified  during  rapid  prototyping  during 
implementation.  Not  every  level  in  the  architecture  will  necessarily  be 
implemented,  some  levds  auod  objects  will  exist  in  design  only  in  order  to  fadUtate 
understanding  of  the  DIS  system.  It  should  be  noted  here  that  the  PDU  structure 
mandated  in  the  DIS  Protocol  Draft  Stan^rd  [1ST,  1991al  is  a  private  matter 
internal  to  the  network  object,  and  are  an  implementation  decision  on  the  format 
of  messages. 

The  Object  Model  of  DIS  will  on  occasion  disagree  with  the  taxonomy  provided 
by  the  DIS  Protocol  Draft  Standard  [1ST,  1991a],  and  on  occasion  it  will  provide 
additional  objects  than  those  found  in  the  Draft  Standard.  This  will  provide  a 
map-hanigm  for  debating  useful  changes  and  extensions  to  the  Draft  Standard 
taxonomy.  The  DIS  hierarchy  is  proposed  as  a  dengn  tool  and  methodology  rather 
than  a  final  plan. 
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Part-of  hierarchies  are  also  required  for  DIS.  For  example,  consider  military 
organizations.  An  Organization  object  in  a  hierarchy  would  specialize  to 

organizations  such  as  Division  a^  Brigade.  But  we  know  that  Brigades  are  a 
Part-Of  Divisions.  Where  is  this  knowledge  contained?  Each  object  contains 
attributes  (slots)  which  help  describe  the  specialization  of  that  object. 
Organization  specializations  will  inherit  firom  the  organization  object  a  "parent 
unit”  slot.  These  slots  will  be  type  restricted,  i.e.  the  "parent  unit”  slot  of  any 
brigade  organization  will  be  restricted  to  objects  which  are  division  organizations, 
those  of  battalions  will  be  restricted  to  objects  which  are  brigade  organizations,  et 
cetera  (see  Figure  3).  Thus  part-Of  hierarchies  are  implicitly  contained  in  the 
Type-Of  hierarchy.  However,  as  part  of  the  architecture  we  must  make  all 
hierarchies  explicit  in  an  objert-oriented  DIS  architecture. 
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Figures:  Hm  Aggregation  (Part>Of)  hiaurchy  for  Uilitary  Task  Organization  is 

implemented  by  restrictions  (typing^  placed  on  the  instance  variables  (slots)  of  the  unit 
classes.  Other  Aggregation  hierarchies  will  exist. 


3.2^  Typing 

T^ing  is  a  valuable  dement  of  the  object  modd,  but  with  the  presence  of  object 
class  in  abstraction  is  not  viewed  as  a  necessary  element.  Type  places  a  different 
emphasis  on  the  meaning  of  abstraction.  It  enforces  the  dass  of  an  object,  such 
that  objects  of  different  types  may  not  be  interchanged  in  any  but  the  most 
restricted  ways  [Booch,  1991].  However,  in  specific  domains  it  may  be  that  typing 
provides  overwhelming  advantages  or  disadvantages,  and  so  the  dedsion  to 
enforce  typing  is  orthogonal  to  the  dedsion  concerning  the  use  of  an  object- 
oriented  approach. 

Typing  will  be  invaluable  for  the  DIS  Architecture,  however,  as  it  wiU  be  used 
to  assist  in  the  construction  of  aggregation  (or  Part-Of)  hierarchies.  For  example, 
the  dass  of  object  called  Unit  may  have  instance  variables  (or  attributes)  Parent- 
Unit  and  Sub-Units.  Objects  which  specialize  Unit,  i.e.  are  Type-Of  Unit,  will 
place  restrictions  on  the  contents  of  ^eir  inherited  Parent-Unit  and  Sub-Units 
variables  by  ^ing  them.  the  Brigade  Unit  dass  will  type  its  Parent-Unit  to  be 
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of  type  Division,  and  its  Sub-Units  to  be  a  set  of  objects  of  type  Battalion  (see  Figure 
3). 

3,2.6  CoDciinnency 


The  DIS  domain  almost  by  definition  calls  for  concurrent  processing  in  that  it 
is  distributed  and  includes  humans  in  the  loop  who  will  generate  different  events 
simultaneously.  The  different  events  in  this  case  are  events  that  are  shared  over 
the  DIS  network,  and  are  thus  public  events.  Concurrent  within  an  application 
on  the  DIS  net  are  private  to  the  implementers  of  that  application.  Concurrency  is 
thus  a  requirement  for  the  DIS  Architecture,  and  for  this  domain  a  necessary 
element  in  any  credible  approach. 

3.2.7  PerFasteJice 

Objects  may  persist  in  time  on  a  continuum  of  existence  [Booch,  1991].  Specific 
instances  of  manned  Ml  simulators,  for  example  an  instance  wi^  given  engine 
reliability,  may  only  exist  for  the  duration  of  a  specific  exercise  (or  until  killed). 
However,  certain  objects  (such  as  map  or  scenario  objects)  may  exist  from  session 
to  session. 

3.3  SafhirareEDgiiieeriiiffBeEiefitsofOOD 

Object-Oriented  design  and  analysis  methodologies  serve  not  only  the 
ardhitectural  design  effort,  but  the  software  implementation  as  well.  These 
benefits  naturally  accrue  because  the  software  is  t^  embodiment  of  the  notional 
Virtual  Battlefield  architecture,  as  well  as  a  key  component  of  the  Simulation 
Support  architecture.  By  tailoring  the  software  implementation  to  the  object- 
oriented  architectural  firamework,  application  system  builders  will  reap  both  cost 
and  time  savings.  Three  features  of  the  object-oriented  architecture  promote  these 
savings. 

•  Superior  Modeling  Representatimi.  The  object-oriented  design  facilitates 
a  superior  modeling  representation  of  the  Virtual  Battlefield.  Because  of 
the  object-oriented  focus  adopted  in  the  design  of  the  Virtual  Battlefield, 
the  conceptual  constructs  that  emerge  offer  a  more  orderly  and  logical 
way  to  analyze,  describe,  document,  and  model  the  chaos  that 
characterizes  the  real  battlefield.  By  following  the  path  of  the  object- 
oriented  architecture,  the  software  implementation  i^erits  this  orderly 
world  view. 

•  Software  Ardiitectara^S^temAitiliitec;tureC<»Telation.  Because  object- 
oriented  analysis  and  design  is  a  system-building  technology,  the 
framework  that  it  defines  can  house  the  software  implementation  as 
well  as  the  system  definition.  Essentially,  the  top-level  software 
structure,  its  architecture,  can  comfortably  decompose  along  the  same 
lines  of  definition  and  description  used  for  the  system  architecture. 
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Thus,  engineering  efifort  expended  to  identify  the  shape  of  the  BDS-D 
system  can  be  immediately  appropriated  into  the  software  design. 

•  Reuaahility.  Structuring  the  software  along  the  notional  lines  defined  by 
the  object-oriented  system  architecture  leads  to  enhanced  software 
reusability.  Each  new  BDS-D  application  starts  with  a  dear  description 
of  its  spe<^c  differences  and  novelties  as  a  new  component  of  the  BDS-D 
system.  This  darify  results  fi^Dm  the  "type-or  dass  hierarchy  used  to 
characterize  an  object-oriented  design.  A  new  implementation  can  thus 
be  described  as  a  refinement  of  a  dass,  or  a  set  of  classes,  already 
identified  and  captured  in  the  object-oriented  architectural  description. 
Software  concepts,  if  not  the  actual  code,  used  to  define  the  parent 
superdasses  can  be  reused  in  the  new  application  to  lend  it  a  canonical 
structure.  By  noting  the  dass  attribute  differences  which  separate 
already-defined  architectural  dasses  from  the  requirements  of  the  new 
application,  the  application  designer  gains  a  dear  understanding  of  the 
path  ahead  to  successful  implementation  and  integration  of  his  new 
component. 

The  combined  effect  of  the  above  three  features  equals  bottom-line  cost  and 
schedule  benefits  to  the  software  engineering  process  of  system  implementation. 
The  following  software  implementation  benefits  are  gained: 

•  Accelerated  software  Development.  Software  development  can  be 
accelerated  because  it  can  follow  the  dearly-mapped  development  path 
provided  by  the  architectural  design.  Additionally,  concepts  and  code 
can  be  reused  firom  one  application  to  the  next,  or  within  the  context  of 
the  same  application  as  the  dass  descriptions  become  progressively 
refined  and  progressively  implem^ted  in  software. 

•  Reduced  Life-Cycle  and  Maintenance  Costs.  Software  systems,  designed 
and  implement^  along  the  object-oriented  paradigm,  will  feature 
reduced  life-cyde  and  maintenance  costs.  Because  the  implementation 
software  has  a  more  logical  and  orderly  internal  composition,  because  it 
more  intuitively  represents  battlefield  dynamics,  one  can  expect  that  it 
will  be  simpler  to  ^sign,  test,  field,  and  fix.  There  will  be  a  stronger  link 
between  the  software  organization  and  what  the  software  models  and 
represents.  Bugs  will  be  easier  to  spot  and  root  out.  New  personnd  will 
be  able  to  master  the  software  in  less  time.  Natural  growth  and 
modification  of  the  software-spurred  by  continued  experience  with,  and 
analysis  of,  the  relevant  technical  challenges-can  be  more  easily 
accommodated  in  the  software  implementation. 

A  key  point  to  consider  is  that  an  object-oriented  architectural  description, 
coupled  with  a  software  architecture  that  is  expressed  along  the  same  lines,  gives 
rise  to  a  new  dimension  of  configuration  management  (CM)  activity,  i.e.  dass 
management.  Traditional  management  of  software  loads,  executable  libraries, 
and  software  source  files  is  now  augmented  by  management  of  the  dass 
descriptions  that  emanate  firom  the  architectural  design. 
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This  new  direction  of  management  activities  should  not  be  considered  as 
merely  an  additional  burden  on  the  CM  function.  Class  management  offers 
something  different  from  the  traditional  CM  activities. 


First,  class  management  offers  enhanced  potential  for  software  reusability. 
The  notional  and  software  architecture  are  defined  in  terms  of  ”type-or  class 
decomposition.  As  software  development  proceeds,  it  is  natural  to  form  the  new, 
lower-level,  more-specific  classes,  by  reusing  the  software  implementation  of  the 
ancestor  superclasses  and  applying  the  new  and  changed  attributes  to  the  new 
descriptions.  Given  this  development  environment,  management  of  the  class 
descriptions  provides  the  jumping  off  point  for  incremental  growth  and 
modification  of  the  system. 

Second,  unlike  object  libraries  and  source  files,  which  constitute  "black" 
system  building  blocks,  offering  no  insight  into  the  structure  of  the  system 
without  the  investment  of  costly  analysis,  ^  dass  descriptions  are  open,  intuitive 
expressions  of  either  the  notional  models  or  the  system  building  bloclu.  Proper 
management  of  these  descriptions  encourages  review  of  the  evolving  system. 

Third,  object  management  facilitates  cross-development,  BDS-D-wide  CM.  The 
overall  architecture  imposes  a  common  structure  on  architecturally-compliant 
software  through  the  spedfication  of  dasses,  their  ancestry,  and  their  attributes. 
Software  components  can  be  defined  and  tracked  not  only  though  their  external- 
system  assigned  functionality  and  names,  but  also  through  their  implementation 
of  the  architecturally-defined  dasses.  System-wide  versions  can  be  identified 
based  upon  the  dass  definitions.  Extexnal  BDS-D  software  applications  will 
inherit  their  revision  level  based  upon  their  linkage  to  the  set  of  defined  version- 
related  dasses. 


3.4  Implementatioin  Conaideratians 
3.4.1  Requirement  fiarOigectOriented  Ada 

The  DIS  architecture  must  take  account  of  the  requirement  to  implement  in 
Ada.  Unfortunately,  Ada  is  Object-Based  rather  than  object-oriented,  since  it  is 
missing  some  of  the  essential  features  of  the  object  model  [Booch,  1990;  Pascoe, 
1986;  Stroustrup,  1988].  In  particular  Ada  fails  to  provide  the  following  [Bach, 
1989]: 

*  direct  support  for  inheritance 

*  object  message  passing 

*  dynamic  binding 

*  instance  or  dass  method  overriding 
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The  lack  of  object  inheritance  seriously  impedes  the  use  of  Ada  in 
implementing  an  object-oriented  design.  At  least  four  approaches  are  possible  in 
dealing  with  this: 

*  Restrict  the  design  to  those  constructs  supported  by  Ada,  and  give  up  the 
nugor  advantages  of  object-oriented  design  in  the  implementation. 

*  Design  according  to  the  full  object  model,  and  optimize  to  a  restricted 
implementation  supported  by  Ada. 

*  Design  according  to  the  full  object  model,  and  wait  for  object-oriented 
constructs  to  be  made  part  of  the  2167A  standard. 

*  Use  COTS  products  which  provide  object-oriented  Ada  pre-processors, 
sudi  as  the  Classic-Ada™  product  line. 

The  design  of  the  DIS  Architecture  should  not  be  compromised  by  the  current 
lack  of  object-oriented  Ada,  since  modifications  to  Ada  will  be  made  to  support 
Object  Orientedness  later,  and  since  there  currently  exist  COTS  systems  to 
provide  object-oriented  Ada  now.  The  DIS  Architecture  should  therefore  be 
designed  to  be  fully  object-oriented. 

3.42  COTS  Standards  far  Distributed  Otgect^Mentedl^yBteim 
3.4.2.1  llieOlgect  Request  Broker 

The  distributed  nature  of  the  DIS,  and  the  use  of  heterogeneous  and  extant 
systems  (which  may  not  have  been  initially  designed  as  object-oriented  systems) 
calls  for  a  generalization  of  the  object-oriented  approach  to  indude  applications  as 
objects.  The  Object  Management  Group  (OMG)  Architecture  is  a  possible 
candidate  to  provide  COTS  tools  and  systems  to  apply  to  this  problem.  The  OMG  is 
an  Industry  Standards  Group  attempting  to  devise  standards  for  the  development 
and  use  of  integrated  software  systems.  They  believe  that  the  costs  and 
complexities  of  future  developed  systems  may  best  be  dealt  with  by  using  an  object- 
oriented  approach.  They  propose  an  ardiitecture  to  provide  "interoperability 
between  applications  on  different  machines  in  heterogeneous  distributed 
environments  and  seamlessly  interconnects  multiple  object  systems"  (see  Figure 
4). 


The  OMG  perceive  systems  to  be  objects  in  their  own  right,  and  extant  non 
object-oriented  systems  are  integrated  by  wrapping  them  wi^  an  object-oriented 
interface  (see  Figure  5).  A  design  for  the  Object  Request  Broker  (ORB)  component 
of  the  OMG  ar^tecture,  the  message  passing  facility  between  heterogeneous 
systems,  baa  been  proposed  by  two  joint  teams  consisting  of  DEC/HyperDesk  and 
Sun/HP/NCR/ODI  [OMG,  1991a,  1991b].  The  OMG  architecture  contains  four 
major  parts: 

•  "The  Object  Request  Broker  (ORB).  Enables  objects  to  make  and  receive 
requests  and  responses." 
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•  "Object  Services.  A  collection  of  services  with  object  interfaces  that 
provide  basic  functions  for  realizing  and  maintaining  objects." 

•  "Clommon  Facilities.  A  collection  of  classes  that  provide  general  purpose 
capabilities." 

•  "Application  Objects.  Specific  to  particular  end-user  applications.  Non 
object-oriented  extant  systems  are  wrapped  by  an  object-oriented 
interfiice  to  the  object  request  broker." 


Application  Objects 


Common  Facilities 


L  - 


Object  Request  Broker 


OOMG 


Object  Services 


Figure  4:  OldectManagemeiitC^iqrArciiitecture  Overview.  Hie  OMG  Architecture 
contains  four  parts  [Soley,  1990];  an  Object  Request  Broker  for  facilitating 
communications  between  objects.  Object  Services  for  realizing  and  maintaining  objects. 
Common  Facilities  providing  general  purpose  class  capabilities,  and  Application  Objects 
which  are  particular  end-user  applications. 
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to  multifacMMl  ttctant  application  to  oxtant  application 


FlguraS:  Wrapping  Existing  Applications.  Interfaring  general  heterogeneous 

applications  within  an  object^riented  paradigm  implies  the  ezistenoe  of  obgeet-oriented 
wrappers  as  interfaces  to  extant  systems  which  were  not  built  using  an  ol:gectH>riented 
^iproadi  [Soley,  1990;  Downes-llartin,  1991]. 


Part  of  the  OMG  effort  is  aimed  at  encapsulating,  or  wrappering,  existing 
(possibly  non  object-oriented)  systems  with  an  object-oriented  inter&ce  (see  Figure 
6).  In  this  approach  the  DIS  systems  themselves  (wargames,  operational 
equipment,  computer  generated  forces  et  cetera,  with  their  associated  hardware) 
become  objects,  as  weU  as  the  simulation  objects  such  as  vehicles,  regiments, 
bridges,  et  cetera.  Thus  the  class  hierardiy  contains  two  logical  ^q)es.  The  object 
class  hierarchy  contains  common  or  j^obal  world  objects,  such  as  "regiment”  for 
example.  Subdasses  are  specialized  classes  that  describe  how  these  objects  are 
actually  treated  by  specific  simulator  systems  (or  operational  equipment).  The 
system  dass  hierarchy  describes  simulator  systems  (or  operational  equipment), 
and  captures  the  exportable  behaviors  (or  messages)  and  embeds  them  in  a  dass 
of  message  descriptions.  One  of  the  dass  of  systems  is  dearly  the  user  machine 
interface  system,  with  appropriate  subclasses  for  each  system  in  the  DIS  system. 

The  wrapper  to  each  system  has  two  inteifaces,  the  interface  to  the  rest  of  the 
virtual  reality,  and  t^  interfiioe  to  its  own  wrapped  system.  The  wrappers  are 
responsible  for  impedance  matching  between  systems,  so^  that  each  system 
observes  tJ^  virtual  reality  in  its  own  terms  and  responds  in  such  a  way  that 
global  consistem^  is  maincained  across  S3fstems,  simulated  objects,  simulated  (or 
real)  time,  and  simulated  space.  In  particular  the  wrappers  are  responsible  for 
miitrhing  the  ochelon  level  objects  by  expansion  and  combination.  T^y  do  so  by 
message  passing  between  the  objects  that  populate  the  wrapper  world.  Ais  the  DIS 
system  grows,  it  is  dear  that  an  increasing  proportion  of  the  overall  system 
knowledge  will  be  contained  in  the  wrapper  world,  and  eventually  it  will  become 
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easier  to  extend  the  system  or  modify  it  by  direct  manipulation  of  the  wrappers 
rather  than  the  original  wrapped  systems.  Thus  the  overaU  system  will  evolve 
into  a  fully  object-oriented  system  over  time.  Tools  for  developing  wrappers  are 
being  developed,  and  at  least  one  is  available  as  a  COTS  product  (see  section  1.5.2.2 
[DEC,  1991]),  dec's  Application  Control  Architecture. 

The  interface  between  the  wrapper  and  the  wrapped  system  raises  an 
interesting  point.  If  the  wrapper  is  not  permitted  to  intrude  deeply  into  the 
wrapped  system,  for  political  ownership  reasons  for  example,  then  the  wrapper 
miist  treat  the  wrapp^  system  like  a  black  box  and  restrict  itself  to  manipulating 
its  input  and  output.  This  raises  temporal  coordination  issues.  One  way  round 
this  is  to  allow  the  wrapper  to  use  the  wrapped  system  to  build  a  sequence  of  short 
simulations,  rather  thim  a  single  large  one,  and  to  integrate  these  in  the  wrapper 
to  provide  the  appearance  of  large  scale  behavior.  T^en  when  messages  fx^m 
other  objects  require  manipulation  of  the  wrapped  system  world,  the  wrapper  can 
discard  the  results  from  the  relevant  small  simulation  and  create  another  in  the 
wrapped  system  using  new  input  data,  and  then  re-integrate  this  new  sub¬ 
simulation  into  the  overall  simulation. 
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Figure  6t  Wrmppering»  or  Encapeolating,  a  DietrUmted  Syeten.  Traditional  otgeet- 
oriented  eysteme  eoneist  of  hierarehiee  of  objects  and  classes  communicating  via 
messages  [Booch  91].  By  analogy,  a  wrappered  system  encapsulates  eadi  system  with  an 
obgectH)riented  interface,  effectively  treating  each  system  as  an  object  [0M6  90.  The 
wrappers  encode  the  exportable  behaviors  in  terms  of  classes  of  object  and  handle  the 
interface  to  the  encweulebed  systems  in  terms  of  subclasses  of  object.  A  class  hierarchy 
of  encapsulated  systems  has  to  be  developed,  as  well  as  the  more  traditkmal  hierarchy  of 
iystem  objects,  to  handle  the  eqmrtable  bdiaviors  of  eadi  wrapped  qrstem. 


The  OMG  Architecture  provides  a  dear  and  compelling  set  of  candidate  tools 
for  the  DIS  Architecture.  Although  the  purpose  of  ^e  OMG  concentrates 
ezplidtly  on  business  and  dvilian  applications,  the  language  used  is  significantly 
similar  to  that  used  to  describe  Distributed  Interactive  Simulation.  In  OMG 
Architecture  terms,  DIS  systems  such  as  computer-generated  forces,  wargimes, 
vehide  simulations  and  operational  equipment  are  simply  ^plication  Objects. 
Extant  DIS  systems  which  are  not  object-oriented  would  be  wrapped  in  an  object- 
oriented  interface.  The  Object  Request  Broker  would  be  responsible  for  the 
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communications  between  the  DIS  Application  Objects.  Within  each  DIS 
Application  Object,  processing  and  communications  would  remain  the 
responsibility  of  that  object 

It  is  dear  that  much  common  ground  exists  between  the  OMG  and  DIS  goals. 
The  DIS  community  should  examine  the  OMG  products  (both  COTS  tools/systems 
and  inteUectual  designs)  and  determine  their  application  to  the  DIS  Architecture 
and  its  implementation.  However,  the  competitive  nature  of  combat  introduces 
temporal  issues  into  DIS  not  found  in  the  OMG  charter.  These  temporal  issues 
must  be  separately  addressed,  and  the  DIS  communities  attention  is  drawn  to 
projects  su<^  as  the  ALSP  project  [Weatherly  et  al,  1991;  Pullen  and  Entzminger, 
1991]  to  determine  the  application  of  its  results  to  tins  problem.  Nevertheless, 
certain  of  the  commercial  products  within  the  OMG  standard  are  exhibiting 
message  passing  rates  that  lie  between  15  and  100  messages  a  second.  These 
products  require  analysis. 

Application  of  object-oriented  technologies  to  the  DIS  Architecture  generate  a 
requirement  for  standards  that  go  fiu*  beyond  the  current  efforts  for  ^stributed 
vehicle  simulation: 

*  The  creation  of  global  object  class  hierarchies. 

*  The  creation  of  system  class  hierarchies. 

*  The  interaction  of  wrappers  with  their  wrapped  systems. 

*  The  distribution  of  objects  in  a  time  critical  environment. 

3.4.2,2  .^ipiKcfttinin  Cmitwnl 

A  number  of  business  products  designed  explicitly  to  assist  in  generating 
object-oriented  wrappers  around  extant  non  object-oriented  systems  for 
integration  with  other  systems  are  being  announced  [OMG,  1991a],  as  are  other 
products  for  implementing  the  OMG  architecture.  For  example,  DEC'S 
Application  Control  Architecture  [DEC,  1991]  is  an  object-oriented  software 
technology  that  facilitates  the  dynamic  linking  of  independently  developed 
applications  across  a  network  by  assisting  in  the  building  of  the  object-oriented 
wrappers. 

"Application  Control  Architecture  (ACA)  is  an  object-oriented  software 
technology  that  facilitates  the  dynamic  linldng  of  independently  developed 
applications  across  a  network.  It  does  so  independently  of  whether  the 
applications  being  linked  were  developed  in  an  object-oriented  manner.  Different 
applications  can  be  combined  like  building  blocks  to  provide  unique  solutions  to 
business  problemr,  especially  in  fields  such  as  CASE,  CAD,  CIM,  electronic 
publishing,  and  dtdsion  support.  ACA  provides  a  mechanism  for  building  the 
object-oriented  wrappers  around  extant  applications,  and  then  connects  them  into 
the  Object  Management  Group  Architecture  [Soley,  1990]  for  integration  with 
other  heterogeneous  applications  [DEC,  1991]." 
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DEC'S  ACA  technology  has  been  developed  in  the  context  of  the  Object 
Management  Group's  Architecture  [Soley,  1990]  for  the  commercial  business 
world.  However,  it  is  dear  that  the  conceptual  similarities  between  this 
commerdal  business  rdated  project  and  DIS  are  strong.  However,  the  business 
application  world  does  not  appear  to  deal  with  the  temporal  consistency 
requirements  of  DIS  [Weatherly  et  al,  1^1]. 

The  ACA  document  [DEC,  1991]  discusses  the  issues  facing  organizations 
developing  integrated  distributed  systems  today,  and  how  ACA  can  solve  these 
issues.  The  document  identifies  three  requirements  for  integrating  existing 
technologies  with  new: 

*  "Existing  investments  in  hardware  and  software  must  be  supported.” 

*  "Existing  and  new  software  applications  should  be  accessible 
throughout  an  organization  to  provide  system-to-system 
interoperability" 

*  "Existing  centralized  computing  systems  at  the  departmental  level 
should  1^  retained  and  combined  with  the  advantages  of  distributed 
computing  environment." 

3A23  Tile  Tool  Talk  Servioe 

Another  recent  COTS  product  of  interest  to  the  DIS  Architecture  is  the 
ToolTalk  Service,  bundled  by  SunSoft  as  part  of  the  Sun  operating  system.  This  is 
a  technology  to  facilitate  inter*application  operation  on  distributed  networks 
[SunSoft,  1991a,  1991b].  In  addition,  much  design  work  and  discussion  on  the 
technical  issues  surrounding  the  OMG  charter  is  available  for  examination 
[Powell  et  al,  1991;  SunSoft  1991c,  1991d]. 

3^  Real  Time  Perfarmanoe 

Real  time  performance  is  a  challenge  when  using  object-oriented 
implementations.  The  DIS  Architecture  vdll  provide  the  full  benefits  of  an  object- 
oriented  design  and  implementation  while  maintaining  real  time  performance 
for  the  simulation.  This  will  be  done  by  clearly  dividing  the  objects  into  dasses 
that  require  rapid  processing  of  methods  (for  example  vehicle  level  objects 
transmitting  PDUs  onto  the  FDDI  and  reading  PDUs  from  the  FDDI  whidh  has  to 
happen  on  the  order  of  many  times  a  second))  and  those  whose  processing  time  is 
not  rapid  (for  example  Unit  Staff  objects  responsible  for  mission  planning,  which 
occurs  over  many  minutes  to  hours).  Rapid  processing  methods  will  be 
implemented  as  optimized  function  calls. 

Many  of  the  products  which  implement  the  OMG  architecture  can  handle 
object  message  rates  between  ten  to  a  hundred  a  second.  This  straddles  the 
internal  update  rate  of  die  DIS  vehide  level  objects,  is  dearly  suffident  for  PDU 
transmission  rates  per  DIS  vehide  levd  entity. 
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3J$  R<wmmu»fnA»tinfna 

Uae  Modem  Software  Engineering.  The  DIS  effort  should  take  advantage  of 
modem  software  engineering  and  become  explicitly  objectH>riented.  If  Ada  is 
mandated,  then  objectoriented  COTS  extensions  to  s^uld  be  used. 

Integrate  DoD  Seamlees  Simulation  and  Industry  OMG  Architecture.  The 
DoD  Seamless  Simulation  effort  should  be  explicitly  integrated  with  the  business 
Object  Management  Group  Architecture  effort  to  integrate  heterogeneous 
business  applications  in  a  seamless  environment,  and  take  advantage  of  the 
related  business  products  in  this  area.  It  is  possible  for  the  OMG  Architecture  to 
be  seriously  considered  as  a  candidate  paradigm  for  DIS,  and  for  the  work  being 
carried  out  in  the  civilian  business  sector  in  this  area  to  be  exploited  by  DIS.  One 
approach  could  be  for  the  University  of  Central  Florida's  Institute  for  Simulation 
and  Training  to  join  the  OMG.  This  would  provide  a  mechanism  for  inserting  DIS 
requirements  into  the  OMG  process,  and  for  the  DIS  to  benefit  from  civilian 
business  investment  in  the  area. 
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Appendix  A:  Computer  Generated  Forces 

Endosed  is  a  r^rint  of  a  Tedmical  Sqxnt  suluDitted  to  FMTRADE  under  the 
ADST  program. 
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Absteact 


This  Technical  Report  for  Step  1  ADST  Task  1  (Advanced  Technologies  for 
Computer  Generated  Forces)  indudes  a  summary  of  the  findings  of  the  Step  1 
efforts  as  applied  to  Computer  Generated  Forces  (CGF)  component  of  the  DIS 
Architecture,  describes  the  problems  to  be  solved,  and  discussed  the  technical 
issues  for  solving  those  problems. 

The  step  1  study  determined  that  four  critical  operational  objectives  of  the 
Computer  Generated  Forces  are  not  being  met  by  the  current  approaches  to  the 
CGF  (see  Figure  1).  These  objectives  are: 

•  Provide  a  modular  and  open  CGF. 

•  Provide  a  CGF  which  incorporates  all  battlefield  functions  and  is 
expandable  is  scale,  scope  and  realism. 

•  Provide  a  CGF  that  supports  generation  of  CGF  platforms  from  the 
manned  platform  simulation  specification. 

•  Provide  realistic  CGF  behaviors. 

•  Provide  user  interfaces  to  the  CGF  which  are  militarily  realistic,  do  not 
overload  the  operator,  and  which  support  both  warfighters  and 
trainers/analysts  as  operators. 

The  step  1  study  determined  that  the  CGF  operational  objectives  could  best  be 
met  by  implementing  a  CGF  Architecture  that  would  permit  the  CGF  to  be 
developed,  implemented,  modified  and  expanded  in  independent  components  by 
multiple  users.  This  is  vital  if  the  BDS-D  DIS  system  is  to  provide  a  rich  and  large 
scale  battlefield  at  low  cost  to  all  DIS  participants,  most  of  who  will  require  a 
simulated  battlefield  to  insert  their  simiilations  but  who  do  not  have  the  resources 
to  create  such  a  battlefield.  Furthermore,  the  step  1  study  determined  that  a  CGF 
behavioral  approach  based  on  an  object-oriented  representation  of  the  military  C3I 
structure  provided  the  best  architecture  for  an  expandable,  modular  and  open 
CGF  capable  of  rapid  demonstration  (see  Figure  2).  Finally  the  step  1  study 
determined  that  su^  an  architecture  is  feasible. 

Proof  of  Concept  demonstrations  of  the  architecture  are  recommended  that 
implement  the  important  features  of  the  CGF  architecture,  demonstrating  the 
feasibility  of  the  modular,  object-oriented  approach,  and  showing  how 
independently  developed  obje<ls  e«n  be  incorporated  to  create  a  CGF  which  keeps 
pace  with  battlefield  advances.  This  proof  of  concept  should  demonstrate  the 
following  component  technologies: 

•  battlefidd  operating  systems  models 

•  an  explicit  simulation  of  tactical  communications 

•  mode&  of  general  human  behavior  on  the  battlefield 

•  a  shared  initiative  system  for  alerting  the  operator  when  the  code  is 
insufficient  for  tihe  task 

•  planning  tools  for  senior  commanders 

•  user  interfaces 


Much  SI,  IMS 


ADST/WDI/rn-SS-OOSOlO 


1  Introduction 


CU>mputer  Generated  Forces  Study.  This  Technical  Report  for  Step  2  ADST 
Task  1  (Advanced  Technologies  for  Computer  Generated  Forces)  includes  a 
summary  of  the  findings  of  the  Step  1  efforts  as  applied  to  the  Computer 
Generated  Forces  (CGF)  component  of  the  DIS  Ardiitecture,  describes  the 
problems  to  be  solved,  and  ^scussed  the  technical  issues  for  solving  those 
problems. 

The  Loral  ADST  Team  has  carried  out  a  Step  1  Study  of  the  Distributed 
Interactive  Simulation  (DIS)  Architecture.  The  residts  of  this  study  are  published 
after  extensive  briefing  to  and  feedback  from  the  government  and  industry.  Part  of 
the  Architecture  Study  dealt  with  the  role  of  Computer  Generated  Forces  (CGF)  in 
the  DIS  battlefield.  It  was  determined  by  the  step  1  study  that  CGF  represented  a 
sufficiently  critical  and  large  component  of  the  DIS  that  the  success  of  DIS 
depended  on  a  credible  architecture  for  the  CGF.  Most  participants  in  the  DIS 
effort  will  want  to  insert  their  system  into  a  rich  and  large  scale  simulated 
battlefield,  but  will  not  have  the  resources  to  create  that  large  scale  battlefield 
(either  in  terms  of  providing  large  numbers  of  manned  platform  simulators  or 
computer  generated  forces).  Thus  the  CGF  are  an  integral  part  of  the  DIS 
infrastructure,  and  an  architecture  must  be  provided  for  them.  This  architecture 
must  support  open  and  independent  development,  modification  and  expansion  of 
the  CGF  by  multiple  users  in  order  to  reduce  the  risks  associated  with  attempting 
to  simulate  human  decision  making  on  the  scale  required  by  a  CGF. 

CGF  Study  Scope.  The  step  1  study  for  Computer  Generated  Forces  examined 
four  mqjor  operational  objectives  for  the  CGF: 

•  Expansion  of  the  CGF  system.  The  CGF  must  grow  as  the  scale  of  the 
DIS  battlefield  grows  in  order  to  provide  a  cost-effective  simulated 
battlefield  populated  with  large  numbers  and  types  of  platforms.  This 
expansion  is  in  terms  scale,  realism  and  scope.  This  will  only  be  feasible 
if  the  CGF  can  be  expanded  in  a  modular  fashion,  each  area  of 
expansion  being  carried  out  independently  of  the  others. 

•  Sco]^  of  CGF  behaviors  available  to  DIS.  The  CGF  must  be  able  to 
provide  a  full  range  of  Battlefield  Functions  and  a  full  combined  arms 
force. 

•  Behavioral  realism  of  CGF  units.  As  the  scale  of  the  DIS  battlefield 
increases,  CGF  forces  will  represent  larger  and  more  complex  units 
than  the  current  company  level  of  command  and  control.  The  CGF  units 
and  platforms  will  have  to  behave  with  increasing  levels  of  realism  and 
rdiability.  In  particular,  CGF  must  explicitly  de^  with  simulated  C3I, 
and  the  resultant  unit  level  coordination  and  synchronization  of  the 
CGF  units. 
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•  Use  of  the  CGF  by  human  operaton.  As  the  scale  of  the  DIS  battlefield 
increases,  human  CGF  operators  will  have  larger  and  more  complex 
CGF  under  their  control.  The  operator  inter&ces  must  be  militarily 
realistic  and  provide  control  of  the  CGF  without  overloading  the 
operator. 

CGF  Study  Appr«>acli.  The  step  1  study  consisted  of  interview  with  SIMNET 
SAFOR  staff  and  students  at  the  Armor  Sclml,  Fort  Kaoz  Close  Combat  Test  Bed, 
study  of  reports  concerning  the  use  of  the  SlhO^lET  SAFOR,  study  of  assessments 
of  the  SD^'lET  SAFOR  in  the  scientific  press,  and  analysis  by  l^e  step  1  study. 
The  step  1  study  assumed  a  CGF  is  required  to  provide: 

•  an  open,  modular  system  capable  of  expansion  in  scope,  scale  and 
realism. 

•  large  numbers  of  DIS  forces  with  low  manpower  requirements. 

•  simulation  of  the  performance  and  appearance  of  manned  simulators. 

•  simulation  of  the  performance  and  appearance  of  platforms  for  which 
no  manned  simulators  exist. 

•  simulation  of  human  decision  making  in  a  simulated  C3I  hierarchy. 

•  user  interfaces  to  any  decision  making  node  in  the  simulated  C3I 
hierarchy  for  the  CGF. 

•  provide  credible  and  realistic  large  scale  battlefield  behaviors. 

These  assumptions,  when  applied  to  the  study  of  current  CGF  technology,  lead 
to  the  four  nugor  conclusions  described  below. 

CGF  Study  Findings.  The  Computer  Operated  Forces  is  currently  treated  as  a 
single  large  system.  It  precludes  independent  development  of  new  modules  to 
support  specific  user  requirements.  It  also  precludes  exploration  of  new  CGF 
approaches  and  implementations  by  multiple  contributors.  The  CGF  however  is 
sufficiently  large  and  complex  that  it  warrants  its  own  architecture  with 
components  capable  of  independent  development,  modification,  and  expansion  by 
multiple  users.  Such  an  architecture  will  decouple  the  risks  associated  with  each 
technical  area  of  the  CGF,  and  permit  a  reconfigurable  CGF  capable  of  expansion 
(by  multiple  independent  users)  without  the  major  rewrites  that  have  plagued  the 
current  system. 

The  step  1  study  determined  that  there  are  four  critical  operational  objectives  of 
the  Computer  Generated  Forces  (see  Figure  1): 

•  Provide  a  modular  and  open  CGF 
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•  Provide  a  CGF  which  incorporates  all  battlefield  fimctions  and  is 
expandable  is  scale,  scope  and  realism. 

•  Provide  realistic  CGF  behaviors 

•  Provide  user  interfkces  to  the  CGF  which  are  militarily  realistic,  do  not 
overload  the  operator,  and  which  support  both  warfighters  and 
trainers/analysts  as  operators 

Furthermore,  these  operational  objectives  are  not  being  fully  met  by  the 
current  technologies  whi<^  are  used  to  implement  Computer  Generated  Forces. 
The  step  1  study  determined  that  the  CGF  operational  objectives  could  best  be  met 
by  implementing  a  CGF  Architecture  that  would  permit  the  CGF  to  be  developed, 
implemented,  modified  and  expanded  in  independent  components  by  multiple 
users  and  application  contributors. 

The  step  1  study  examined  a  variety  of  techniques  that  have  been  employed  or 
proposed  for  generating  Semi-Automated  Forces  behaviors,  as  well  as  some 
others  that  might  be  considered  feasible,  and  an  analysis  of  the  benefits  and 
drawbacks  of  l^ese  approaches  was  made  (see  Figure  2).  The  current  Combat 
Instruction  Set  (CIS)  approach  of  explicitly  enumerating  all  behaviors  was 
determined  to  provide  useful  small  unit  tactical  modules.  However,  it  is  not 
expandable  to  large  scale  simulated  battlefields  due  to  the  virtually  infinite 
numbers  of  behaviors  that  would  have  to  be  enumerated,  the  lack  of  a  CIS 
approach  to  C3I  for  larger  units,  and  the  problems  of  the  rule-based  approach  to 
human  behavior  that  the  CIS  employs. 

The  step  1  study  determined  that  a  CGF  behavioral  approach  based  on  an 
object-oriented  representation  of  the  military  C3I  structure  provided  Uie  best 
architecture  for  an  expandable,  modular  and  open  CGF  capable  of  rapid 
demonstration.  This  woidd  also  facilitate  the  transition  into  the  public  domain  of 
the  current  SAFOR  CIS  modules  by  embedding  them  in  a  simulated  C3I 
structure  which  supports  the  large  s^e  battlefield.  Thus  past  investments  in 
SAFOR  would  be  exploited.  Finally  the  step  1  study  determined  that  such  an 
architecture  is  feasible,  and  proof  of  the  concept  demonstrations  are 
recommended. 

Proofof  Concept  Demonstration  f<Hr  Open  CCS*  Architecture.  Proof  of  Concept 
demonstrations  of  object  oriented  CGF  architectural  components  are 
recommended  in  four  areas  (see  columns  2  and  3  of  Figure  1): 

•  Battlefield  operating  systems  models 

•  General  human  behavior  on  the  battlefield 

•  A  shared  initiative  system  for  alerting  the  operator  when  the  code  is 
insufficient  for  the  task 

•  User  interfoces 


Maxch  81,1981 


AD8TAn>I/m~98-008010 


A  general  objectK>riented  model  of  human  behavior  decomposed  into  a  small 
ntunber  of  action  and  cognition  components  is  recommended,  based  on  the  study 
of  alternative  approaches  to  CGF  b^aviors  (see  Figure  2).  These  components  are 
combined  into  the  tasks  and  subtasks  defined  by  TRADOC's  Blueprint  of  the 
Battlefield  [Pam  11*9],  which  in  turn  are  combined  into  Battlefield  Operating 
System  objects.  The  BOS  objects  are  combined  into  CGF  decision  making  nodes  in 
the  CGF  command  hierarchy.  Small  amounts  of  code  in  defined  module  libraries 
may  thus  be  configured  in  many  ways  to  produce  a  wide  range  of  behaviors.  These 
behaviors  are  easily  r«iConfigurable  due  to  the  modularity  of  the  approach.  CGF 
objects  are  distinguished  from  each  other  by  data  which  defines  the  combinations 
of  behaviors  they  are  permitted  to  perform,  thus  reducing  the  risks  associated 
with  large  bodies  of  code.  The  user  interfaces  are  generate  by  COTS  Graphical 
User  Interface  (GUI)  generators,  and  determine  the  access  privileges  to  the 
various  functions  of  ^e  CGF  objects,  thus  providing  both  warfighters  and 
trainer/analysts  with  appropriate  interfaces  based  on  a  common  system.  The 
featxires  and  benefits  of  these  technical  approaches  are  described  in  columns  4 
and  5  of  Figure  1. 

The  extant  SAFOR  CISs  (from  all  government  funded  SAFORs)  should  be 
investigated  as  CGF  platform  and  snudl  unit  drivers  to  be  embedded  into  the 
recommended  CGF  architecture.  A  robust  and  mature  C3I  simulation  and 
wargaming  simulation  should  be  identified  for  implementing  CGF  C3I  and  CGF 
unit  behaviors,  and  behavior  combination.  One  possibility  identified  by  the  step  1 
study  is  the  Simulated  Warfare  Environment  Generator  (SWEG).  SWEG  is  a 
mature  and  robust  warfare  simulation  tool  for  unit  and  platform  levels  of 
interaction  used  by  the  U.S.  Navy  at  Patuxent  River  Naval  Air  Station  (NAS)  on 
the  Aircraft  Combat  Environment  Test  and  Evaluation  Facility  (ACETEF)  and  by 
the  U.S.  Navy  at  China  Lake  on  research  and  development  efforts.  Both  the 
selected  C3I  simulation  and  SAFOR  CISs  should  be  used  as  components  of  an 
ardutecture  proof  of  concept  demonstration  to  test  the  open  nature  of  the 
approach  and  the  feasibility  of  exploiting  past  investments  in  CGF  and 
Wargaming. 

Technical  Innovationa.  Seven  major  areas  of  innovation  are  recommended  as 
immediate  requirements  to  support  the  operational  objectives  of  the  DIS 
Computer  Generated  Forces  (CGF)  system  (see  Figure  1).  Each  of  the  operational 
objectives  can  be  implemented  independently,  by  selectively  providing  the 
respective  technical  innovations,  thus  redudng  risk.  In  addition,  each  technical 
innovation  has  general  uses  in  other  areas  of  defense  modeling  and  simulation, 
thus  providing  a  clear  path  for  technology  transfer  to  other  programs  and 
integration  wi&  other  programs.  The  miqo^  areas  of  technical  innovation  are: 

1  Open  and  Documented  Architecture.  The  CGF  architectuxe  should  be 
open,  with  its  defined  interfaces  documented  and  its  code  made  public. 

All  models  used  to  demonstrate  the  CGF  architecture  should  be  provided 
as  non-proprietary  and  fully  documented.  This  includes  the  design  and 
technology  as  weU  as  the  c^e  documentation.  Previous  investments  in 
SAFOR  (using  Combat  Instruction  Sets  and  other  government  funded 
approaches)  and  Wargaming  (using  the  SWEG  Simulated  Warfare 
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Environment  Generator  for  example)  should  be  investigated  as  modules 
in  the  architecture,  thus  proving  the  open  nature  of  the  architecture. 
Maximum  use  should  be  made  of  COTS  products.  The  C  higher  order 
programming  language  should  be  used  in  order  to  obtain  the  benefits  of 
rapid  prototyping.  The  architecture  components  should  be  transitioned 
to  Ada  on  a  module  by  module  basis  as  their  utility  is  proven.  This 
approach  will  also  transition  the  ciurent  CIS  based  SAFOR  into  the 
public  domain. 

2  Battlefield  Operating  System  Models.  The  design  of  the  DIS  CGF  should 
make  explicit  use  of  the  Army  Training  and  Doctrine  Command’s 
Blueprint  of  the  Battlefield  [TBADOC  Pam  11-9],  and  similar  doctrinal 
statements  firom  the  other  services,  to  build  its  taxonomy  of  the  objects  on 
the  battlefield.  The  CGF  should  support  complete  interchangeability  of 
human  operators  and  software  simulations  of  decision  makers  via  the 
user  interface  to  the  BOS  simulations.  The  code  libraries  of  the  BOS 
simulations  should  be  modular  and  independent. 

3  Tactical  Communications  Simulation.  An  explicit  simulation  of  the  C2 
BOS,  including  Tactical  Communications,  is  recommended  to  generate 
realistic  unit  behavior  by  providing  communications  between  human 
and  software  CGF  decision  makers.  This  would  provide  system  hooks 
for  electronic  warfare,  intelligence  analysis,  and  direct  speech 
communications  between  CGF  and  manned  platforms. 

4  Realistic  CGF  Behaviors.  The  design  and  implementation  of  the  BOS 
based  CGF  behaviors  should  be  based  on  a  general  and  flexible  biunan 
behavioral  engineering  decomposition  of  all  CGF  battlefield  behaviors 
into  Action  (physical  processes)  and  Cognition  (decision  making) 
modules.  The  Action/Cognition  decomposition  is  sufficiently  general 
that  it  can  be  applied  to  a  broad  spectrum  of  battlefield  fimctions. 

6  Alert  Agent.  For  the  forseeable  future,  code  will  not  be  able  to  completely 
replace  human  battlefield  decision  making.  Thus  a  mechanism  is 
required  in  the  CGF  architecture  for  handling  shortfalls  in  code 
capabilities.  An  independent  shared  initiative  system  for  alerting  the 
C(jF  operator  when  code  is  failing  to  maintain  a  desired  level  of  realism 
should  be  provided  by  the  CGF  architecture.  This  "Alert  Agent"  should 
operate  woithout  overloading  the  operator  with  alerts,  and  should  rank 
the  alerts  in  order  of  importance.  The  Alert  Agent  module  is  separate 
from  the  behavior  generation  modules  and  is  independently 
implemented. 

6  User  Interfaces.  The  user  interfaces  to  the  CGF  for  warfighters, 
trainer/analysts  and  developers  should  be  based  on  a  common  system 
and  be  distinguished  from  each  other  by  the  level  of  access  granted  to 
different  user  interface  components.  Thus  a  flexible  and  low  cost  "dual 
use”  system  can  be  provided,  supporting  warfighters  "fighting  to  win" 
as  well  as  trainers,  analysts  and  developers  who  control  the 
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environment  of  the  warfighters.  The  user  interface  windows  should  be 
designed  and  implemented  using  COTS  Graphical  User  Interface  (GUI) 
Generators. 

7  Behavioral  Databases.  Every  object  in  the  CGF  system,  including  the 
definitions  of  behavior,  should  be  defined  by  data,  and  distinguished 
from  similar  objects  by  data.  These  data  objects  should  be  available  for 
inspection,  modification  and  development  by  non-programmer  military 
experts.  By  defining  the  CGF  behaviors  in  an  object-oriented  fashion 
using  data  the  CGF  architecture  should  keep  the  amount  of  executable 
code  to  a  minimum,  thus  reducing  risk  and  maintenance  costs  and 
increasing  expandability  by  military  experts.  These  databases  are  part  of 
the  common  ^tabases  defined  by  the  DIS  Architecture. 

Once  a  proof  of  concept  demonstration  has  been  undertaken,  an  initial 
architecture  with  interface  specifications  will  be  available  to  facilitate  the 
specification  and  open  procurement  of  additional  CGF  features  as  resources, 
budgets,  and  priorities  dictate.  The  following  five  technical  innovations  can  be 
immediately  identified  as  recommended  areas  of  future  effort  to  be  planned  now: 

1  Transition  to  Ada  on  a  module  by  module  basis  and  provide  production 
level  documentation  for  those  modules  proven  to  be  effective.  Continue 
R&D  on  those  modules  requiring  further  work. 

2  Integrate  the  CGF  with  Higher  Order  Models  such  as  the  ALSP 
program  (A^egate  Level  Simulation  Protocol)  in  which  CGF  code  is 
used  to  drive  platform  level  representations  of  the  units  being 
commanded  and  controlled  by  the  higher  order  model. 

3  Distribute  the  BOS  components  of  the  CGF  architecture  across  the  DLS 
network  by  extending  the  DIS  message  protocol  to  include  C3I  messages 
between  t^  CGF  components. 

4  Develop  decision  making  tools  tor  the  CGF  commanders  by  eaqpanding 
on  the  C2  BOS  component  of  the  CGF. 

6  Develop  adaptive  behaviors  within  the  CGF  architecture,  by  which  the 
CGF  demonstrates  automatic  learning  and  exploration  using 
techniques  such  as  neural  nets,  genetic  algorithms,  synthetic 
annealing,  and  feedback  from  the  alert  agent. 
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Flcore  1  SimmiBiy  ot  the  CGF  Arehiteetare  Reooiniiieiidalioii  demonstratM  Uiat  the  operational  ol^jeetivee  for  the  CGF  lyatem  are  flilly  aupported  by  the 

recommended  COF  Ardiiteetiire.  Each  of  the  four  m^jor  operational  objectivee  generate  techni^  challengea  which  must  be  dealt  with  1^  tedinical  innovationa 
in  CGF  techndogy.  Theae  technical  innovationa  have  featorea  and  ben^ta  which  not  only  support  the  operational  objectives,  but  also  provide  a  technology  base 
for  other  defense  modeling  and  simulation  programs. 


2  The  CGF  Entity  Representatiop 
2.1.  Comparative  Study  Overview 

Critical  and  central  to  the  whole  CGF  issue  is  that  of  CGF  object 
representation  and  behavior  generation.  Thus  this  issue  is  dealt  with  here  in 
some  considerable  detail.  The  CGF  must  exhibit  realistic  behaviors  at  both  the 
platform  level,  and  at  multiple  organized  unit  levels  of  command.  When  unit  level 
behaviors  are  considered,  the  ability  to  represent  human  communications, 
learning  from  experience,  and  exploration  of  new  approaches  within  the  CGF  is 
critical  if  the  CGF  are  to  appear  realistic.  The  main  technical  implication  here  is 
the  requirement  for  a  representation  of  battlefield  behavior  at  the  general  level  of 
human  behavior  in  order  to  support  the  simulation  of  realistic  CGF  behavior 
(exhibiting  innovation  and  learning,  for  example).  The  representation  of  human 
behavior  must  be  flexible  enough  to  support  all  doctrinal  behaviors  implied  by  the 
expansion  objective.  The  human  CGF  commander  must  be  able  to  operate  the 
C(}F  in  such  a  way  that  his  own  military  abilities  are  reflected  by  the  CGF,  thus 
providing  a  critical  element  of  CGF  realism. 

A  study  of  the  various  approaches  (implemented  and  proposed)  to  generating 
CGF  behaviors  was  made,  and  their  various  advantages  and  disadvantages 
considered.  A  wide  range  of  potential  technological  approaches  are  available  for 
use  in  the  CGF.  Some  of  these  technologies  have  been  used  in  current  SAFOR 
systems,  and  the  lessons  learned  from  their  use  are  a  valuable  indicator  of  their 
usefulness.  It  is  dear  that  a  single  technology  will  not  suffice,  a  careful 
integration  of  a  combination  of  technologies  is  required  in  order  to  produce  an 
effective  CGF.  The  selection  and  integration  of  these  technologies  is  critical  to 
producing  a  robust  CGF  system  that  is  low  cost,  low  risk,  and  satisfies  the 
operation  requirements.  This  must  be  done  without  generating  a  high  risk 
technologically  complex  integration  problem.  Four  of  the  various  approaches  are 
discussed  in  some  detail  here  since  these  are  the  most  commonly  used  or 
proposed  technologies  (see  Figure  2): 

•  A  black  box  approach,  in  which  behaviors  are  modeled  by  analogy  to 
some  physical  process. 

•  An  enumeration  approach,  in  which  behaviors  are  exhaustively  defined 
in  detail. 

•  A  rule  baaed  expert  system  approach,  in  which  situations  are  matched 
to  required  behavioral  reactions. 

•  An  object  based  behavioral  decomposition  approach,  in  which  the 
dedsion  making  behaviors  of  the  C3I  hierarchy  are  explidtly  modeled 
on  the  real  world  to  produce  subordinate  level  behaviors  for  units  and 
platforms. 
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The  object  based  behavioral  decomposition  approach  is  recommended  as 
providing  an  architecture  that  is  capable  of  supporting  open  and  modular 
development  of  a  CGF  which  is  expandable  in  scale,  scope  a^  realism. 
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B  S  AnalyslB  of  Some  Diifereiit  ApproocheB  to  CGF  Behavior  Generation.  Object  based  behavioral 

iposition  was  judged  the  best  modular  long  term  technol(^  for  Computer  Generated  Forces. 


The BlackBos Approach 

The  black  box  approach  attempts  to  model  the  resulting  behavior  of  human 
decision  wialcing  in  terms  of  some  well  understood  physical  process.  A  common 
example  is  to  model  platform  navigation  through  a  terrain  by  a  potential  field 
theory,  in  which  the  platform  is  given  a  magnetic  (or  electric)  charge  and 
attempts  to  maneuver  through  a  terrain  consisting  of  magnetic  (or  electric)  fields. 
The  platform  behavior  becomes  a  combination  of  intention  (i.e.  an  acceleration 
vector  of  where  the  platform  is  intended  to  travel)  with  attractors  (vaUeys)  and 
repulsors  (hills,  other  platforms).  The  advantages  of  this  approach  are,  first,  that 
it  is  based  on  simple  models  of  well  understo^  physical  processes.  Second,  it  is 
relatively  cheap  to  execute  as  far  as  hardware  is  concerned. 

However,  the  disadvantages  are  considerable.  There  is  no  dear  relationship 
between  real  world  human  behavior  characteristics  and  the  parameters  of  the 
physical  parameters.  The  physical  model  does  not  contain  a  representation  of 
human  behavior,  thus  it  cannot  be  understood  by  the  militaiy  user  who  is  not  an 
expert  in  the  physical  model.  Human  behavior  and  intention  have  massively 
many  more  characteristics  than  simple  physical  models.  Thus  attempts  to 
upgrade  the  model  in  terms  of  changing  the  simulated  human  behavior  will 
either  require  a  new  physical  model  that  will  then  ignore  the  previous  behaviors, 
or  will  require  a  massively  complex  physical  model.  The  latter  removes  all  the 
advantages  of  this  approach. 

2,3.  The  Enumeration  sqiproach 

The  enumeration  approach  is  that  used  by  the  current  CIS  based  SAFOR.  It 
attempts  to  define  all  required  battlefield  Iwhaviors  both  exhaustively  and  in 
detail.  The  advantages  of  this  approach  are  that  specified  behaviors  are 
guaranteed  to  be  present.  Any  behavior  spedfied  by  the  requirements  are 
explidtly  inserted.  It  is  also  a  very  simple  approach.  The  capabilities  of  the  system 
are  exactly  defined  by  the  enumeration  of  behaviors.  Finally  it  provides  an 
invaluable  library  of  vehide  and  small  imit  (platoon)  behaviors  as  input  data  to  a 
general  architecture  (but  not  the  final  behavioral  system,  and  only  if  a  careful 
analysis  is  done  of  which  small  numbers  of  behaviors  should  be  enumerated 
rather  than  attempting  a  complete  enumeration). 

The  disadvantages  however  remove  a  pure  enumeration  model  firom  the  list  of 
viable  approa^es.  The  niunber  of  required  behaviors  are  massive,  and  a  virtually 
infinite  number  of  behaviors  must  be  defined  for  a  SAFOR  that  has  the  same 
behavioral  fidelity  as  manned  units  and  platforms.  This  is  because  there  does  not 
exist  any  approach  for  automating  the  combination  of  behaviors  in  the 
enumeration  approach,  thus  every  required  behavior  has  to  be  hand  coded.  One 
result  of  is  that  if  a  specific  behavior  is  not  coded,  then  the  system  is  not 
capable  of  reacting  with  t^t  behavior.  Furthermore,  simple  enumerations  of 
behaviors  lead  to  predictable  and  robotic  reactions.  However,  most  importantly, 
the  approach  does  not  scale  to  large  systems.  The  enumeration  of  behaviors  in  t^ 
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2^  TlieOlgec^  Oriented  BehaidoralDeocmipositionApproadi 

Object  oriented  behavioral  decomposition  is  an  approach  in  which  the  C3I 
structure  of  the  battlefield  is  explicitly  represented  and  based  on  the  real  world  to 
produce  subordinate  level  behaviors.  The  advantage  of  the  object  based  behavioral 
decomposition  is  primarily  that  it  provides  an  architecture  that  is  explicitly  based 
on  the  objects  of  ^e  real  world  and  their  interactions.  As  battlefield  requirements 
change,  ^e  architecture  supports  the  reconfiguration  of  the  CGF.  It  explicitly 
represents  the  Unit  level  actions  and  behaviors  as  weU  as  Platform  actions  and 
behaviors.  An  explicit  representation  of  doctrine  based  on  TRADOC's  Blueprint  of 
the  Battlefield  IPam  11-9]  is  used.  This  approach  avoids  the  problems  of  the 
enumeration  approach,  in  that  relatively  sxnall  numbers  of  types  of  object  exist, 
specific  objects  being  distinguished  by  simple  data  files.  Many  objects  are 
represented  as  combinations  of  other  objects.  Each  object  type  is  defined  and 
implemented  independently,  thus  reducing  risk  and  increasing  code  sharing. 
Similarly,  small  numbers  of  simple  behaviors  are  developed  and  combined  to 
form  the  full  variety  of  complex  behaviors  similar  to  the  real  world. 

The  disadvantages  that  have  to  he  dealt  with  are  that  it  is  potentially  compute 
intensive  in  execution  insofar  as  it  represents  the  complexity  of  the  real  world, 
and  that  the  complexity  of  the  real  world  objects  may  be  carried  over  into  a 
complex  model. 

2.6.  The  Step  1  Study  Recommendatiop 

An  analysis  of  the  advantages  and  disadvantages  of  each  of  the  above 
technologies  indicate  that  no  single  technology  will  satisfy  the  CGF  operational 
requirements.  A  combination  of  techniques  is  required,  but  this  combination 
must  be  kept  to  the  smallest  set  of  tedmologies  to  manage  the  complexity  of 
integration.  The  study  team  believes  that  the  best  CGF  is  obtained  by  providing  an 
open  architecture  based  on  the  Object  Based  Behavioral  Decomposition.  The 
disadvantages  of  this  approach  listed  above  are  outweighed  by  representing  much 
of  the  behavior  and  object  definitions  in  data  files  instead  of  in  explicit  code,  thus 
reducing  the  actual  code  execution  time.  In  addition,  object  oriented  approaches 
are  explicitly  designed  to  control  complexity.  Optimization  to  function  calls 
instead  of  object  message  passing  at  the  platform  level  of  execution  will  ensure 
efficient  use  of  compute  resources. 

The  study  recommends  that  this  approach  to  CGF  behavior  generation  is 
demonstrated  within  the  recommended  CGF  architecture  to  demonstrate  both  the 
architectural  concept  and  the  approach  to  CGF  behavior  generation.  The  proof  of 
concept  for  the  object  based  behavioral  decomposition  would  paction  human 
battlefield  behavior  into  Action  (physical  processes)  and  Cognition  (decision 
making)  components.  The  Action  and  Cognition  components  would^  be 
implemented  with  a  s«n»ll  number  of  general  functions,  whose  combinations 
generate  an  extremely  wide  range  of  behaviors.  There  are  only  a  small  number  of 
Action  and  Cognition  tasks  (twelve  in  aU),  and  so  implementation  at  this  level 
becomes  low  risk.  However,  by  combining  these  tasks  it  is  possible  to  generate  the 
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full  range  of  human  behaviors  once  the  data  that  defines  each  function  and 
echelon  have  been  provided. 


3  OpenCXxFAxcliitectiire 

3.1.  CGF  within  the  DlSArahitecture 

Figure  3  shows  an  operational  view  of  the  CGF  objects  and  their  relationships 
to  ea^  other  and  to  hilly  manned  objects  on  the  DIS  battlefield.  CGF  decision 
nodes  (for  example,  command  posts)  are  interacting  with  fully  manned  command 
posts,  and  with  CGrF  platforms  and  manned  platform  simulators  in  mixed  task 
organizations.  Note  t^t  the  CGF  contains  two  top  level  types  of  object,  CGF 
platforms  and  CGF  decision  makers.  The  CGF  decision  makers  are  abstract,  in 
that  liiey  are  simulations  of  human  decision  making  within  the  C3I  heirarchy 
(along  with  user  interfaces).  They  are  instantiated  as  the  platforms  associated 
with  the  decision  nodes  (command  posts)  along  with  their  internal  battlefield 
operating  system  objects  and  intellectual  processes.  CGF  platforms  (both  combat 
and  decision  node  platforms)  interact  with  the  rest  of  the  DIS  world  in  using  the 
familiar  collection  of  move,  shoot,  communicate,  see,  and  sustain.  The  CGF 
decision  nodes  interact  entirely  at  the  level  of  information  flow,  passing  orders, 
requests  for  information,  and  information  between  themselves  and  fully  manned 
elements  via  the  communications  assets  within  the  platforms  that  are  associated 
with  their  instantiations.  In  this  architecture  all  (3GF  decision  making  is  thus 
vulnerable  to  combat  damage,  both  physical  (the  CGF  decision  makers  can  be 
killed)  and  informational  (the  communications  between  the  decision  makers  and 
the  rest  of  the  battlefield  can  be  disrupted  or  monitored). 

Figure  4  shows  the  top  level  DIS  Architecture  developed  by  the  step  1  study, 
and  indicates  the  position  of  the  CGF  within  that  architecture.  In  order  to  achieve 
the  fundamental  DIS  goal  of  interoperation  of  heterogeneous  simulations,  it  is 
useful  to  view  the  DIS  Architecture  as  a  collection  of  cells  interconnected  by  inter¬ 
cell  networks.  Standard  DIS  cells  are  collections  of  homogeneous  simulation 
nodes,  using  the  DIS  message  protocol  for  internal  communication.  Within  a 
Standard  DIS  Cell,  all  simulation  nodes  use  a  fully  compatible  set  of  simulation 
models  and  algorithms;  all  share  a  common  environment  defined  by  an 
environment  database;  and  all  communicate  via  broadcast  datagram  messages. 
Non-Standard  DIS  Cells  are  systems  connected  to  the  DIS  inter-cell  network  but 
whose  internal  structure  is  outside  the  scope  of  the  DIS  architectme.  In  other 
words,  non-standard  DIS  cdls  are  systems  whose  internals  do  not  use  the  DIS 
standards.  Cells  themselves  (both  standard  and  non-standard)  are  heterogeneous 
with  respect  to  each  other,  and  thus  their  interconnection  achieves  the  DIS  goal  of 
heterogeneity. 

Multiple  CGF  entities  within  a  standard  DIS  cell  interact  with  manned  vehide 
simulators  within  the  same  cell.  Additional  standard  DIS  cells  are  on  the 
network  (as  are  non-standard  cells).  Examples  of  manned  platform  simulators 
indude  DIS  platforms  such  as  RWA  at  Fort  Rucker  or  SIMf^T  platforms  such 
as  those  at  Fort  Knox. 
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HgureS  The  CGF  Operational  Andiitecture  for  DI8  integrate*  manned  and 
simulated  command  posts  with  manned  and  CGF  platforms.  The  CGF  Emulates  realistic 
unit  level  behavior  and  platform  behaviors  based  on  TRADOC  Blueprint  of  the  Battlefield 
functions  and  manned  simulator  performance.  An  explicit  simulation  of  tactical 
communications  supports  realistic  C3L 
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3^  System  ArcMtecturoCarCSGFDemoiistra^ 

Figure  5  shows  the  system  architecture  of  the  CGF  node  of  Figure  4  in  a 
standard  DIS  Cell.  In  order  to  implement  such  an  architecture,  a  general  model 
of  human  battlefield  behavior  is  recommended  based  on  Action  (platform)  and 
Cognition  (decision  making)  components.  These  are  combined  into  Battlefield 
Operating  Systems  defined  by  TRADOC's  Blueprint  of  the  Battlefield  [Pam  11-9] 
(and  similar  doctrinal  functions  defined  by  the  other  services).  A  Tactical 
Communications  simulation  component  of  the  C2  BOS  is  explicitly  required  to 
provide  realistic  cooperative  behavior  between  CGF  units  and  realistic  C2  of  the 
CGF  units  by  human  commanders  (see  Figure  3).  All  CGF  decision  nodes 
interact  via  this  tactical  communications  simulation.  An  alert  agent  simulation 
is  required  to  provide  warning  to  the  operator  when  the  code  is  insufficient  to  deal 
realistically  with  a  situation,  and  to  control  the  level  of  loading  on  the  CGF 
operator. 

Extant  government  fimded  SIMNET  code  modules  should  be  used  as  platform 
and  small  unit  drivers  as  appropriate  in  order  to  build  on  p^^tvious  investment 
and  to  transition  this  investment  into  the  open  domain.  A  connection  object  is 
used  to  handle  message  passing  within  the  CGF  processes,  and  via  the  relay 
object  to  the  DIS  network  (cell  tier,  see  Figure  4)  using  a  DIS  network  driver.  Thus 
use  of  SIMNET  code  modules  and  connectivity  to  the  DIS  (cell  tier.  Figure  4)  are 
decoupled  into  independent  technical  decisions.  All  objects  should  heavily  data 
driven,  and  be  distinguished  from  each  other  by  data  ffies. 
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3^  Distributed  CGP 


The  Step  1  Study  recommends  that  the  CGF  architecture  is  implemented  in 
two  major  phases  in  order  to  control  the  impact  of  die  CGF  on  the  DIS  message 
protocol  standards 

In  Phase  1  the  CGF  decision  nodes  are  implemented  in  an  object  oriented 
fashion  (based  on  the  BOS  objects),  with  each  decision  node  an  entity  whose 
internals  (the  BOSs)  are  private  as  ^  as  the  DIS  network  is  concerned.  The  (?GF 
decision  nodes  interact  with  each  other,  with  CGF  platforms,  and  wiUi  manned 
command  posts  and  platforms  via  the  simulation  of  tactical  communications. 
Note  that  the  existence  of  a  CGF  tactical  communication  simulation  haa  an  effect 
on  the  DIS  message  protocol  standard.  CGF  tactical  communications  must 
contain  data  representations  of  the  message  for  receipt  by  CGF  software  decision 
makers  as  well  as  digitized  speech  (for  receipt  by  human  platform  crews).  The 
internals  of  the  CGF  decision  making  node  (e.g.  command  post)  should  be 
implemented  in  an  object-oriented  fashion  to  facilitate  code  reuse,  sharing  and 
reconfiguration. 

In  Phase  2  The  CGF  BOS  objects  are  distributed  over  the  DIS  networks,  thus 
permitting  geographically  distributed  BOS  developers  and  users  to  combine  their 
objects  into  CGF  decision  nodes  (see  Figure  6).  If  the  BOS  objects  are  distributed 
over  the  network  (either  intra-cell  tier  or  inter-ccdl  tier)  then  the  DIS  message 
protocol  will  need  an  entire  new  class  of  standards  to  handle  intra-CGF  node 
(inter-BOS)  messages.  Note  that  inter-BOS  communications  is  often  a  simulation 
of  the  face-to-face  communications  by  the  people  being  simulated  by  the  CGF. 
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4  Open  CGFTcyJmnlngieg 
4.1.  Batdefieild  Operating  Slyst^ 

The  DIS  system  is  expected  to  deal  with  all  the  battlefield  fimctional  areas  in 
an  integrated  fashion.  The  main  technical  implications  of  this  operational 
objective  is  that  the  CGF  software  must  now  exhibit  organized  behavior  in 
addition  to  that  imposed  by  the  human  commander.  This  raises  the  numbers  of 
types  of  behavior  dramatically  beyond  that  dealt  with  by  current  CGF 
technologies.  A  technical  innovation  must  be  implemented  that  supports  a 
potentially  infinite  number  of  behaviors  without  requiring  massive  programmer 
resources.  These  behaviors  must  be  based  on  doctrinal  analyses  of  the  battlefidd, 
and  be  flexible  enough  to  support  changes  to  such  analyses  as  the  world  changes. 
One  example  of  a  critical  behavior  is  the  ability  to  represent  C3I  behaviors,  since 
this  type  of  behavior  is  essential  to  battlefield  fimctional  integration. 

The  CGF  should  contain  explicit  simulations  of  decision  making  objects  (such 
as  command  posts)  organized  according  to  US  and  Threat  Task  Organizations. 
These  decision  making  objects  should  be  developed  in  a  modular  fashion,  with 
component  objects  being  the  Battlefield  Operating  Systems  (BOS)  defined  by 
TRADOC's  Blueprint  of  the  Battlefield  (and  other  doctrinal  representations 
defined  by  the  other  services).  The  Decision  Making  objects  communicate  with 
each  other,  with  CGF  platforms,  and  with  CGF  operators  via  a  simulation  of  the 
tactical  communications  system  contained  in  the  Command  and  Control  (C2)  BOS 
(see  Figure  3).  Thus  CGF  Decision  Making  Objects  (such  as  CPs)  are  simulators 
implemented  using  a  modular  approach  analogous  to  MODSIM.  Each  CGF 
decision  making  object  is  a  combination  of  the  doctrinal  BOS  objects,  where  each 
BOS  object  is  modified  by  data  files  whidi  depend  on  the  type,  size,  axul  color  (US, 
Russian  or  other  threat)  of  the  unit. 

The  recommended  CGF  Architecture  approach  tracks  the  seven  Battlefield 
Operating  Systems  (BOS)  firom  the  Blueprint  throu|^  their  subfunctions  to  all  365 
designated  tasks.  In  parallel  with  this,  a  command  level  hierarchy  is  explicitly 
structured  which  accounts  for  both  the  action  and  cognitive  elements  of  the  BOS 
and  how  they  interact  to  form  the  specific  unit  and  platform  objects  represented 
on  the  virtual  battlefield.  All  CGF  objects  are  built  on  combinations  of  the  small 
number  of  doctrinal  Battlefield  Operating  Systems  and  their  functions  and  tasks. 
There  are  only  a  small  number  of  BOS  objects  and  tasks,  and  so  implementation 
at  this  level  b^mes  low  risk.  However,  by  combining  these  BOSs  and  tasks  it  is 
possible  to  generate  the  full  range  of  battlefield  fimctions  once  the  data  that 
defines  each  BOS  and  task  have  been  provided.  Each  of  the  CGF  Battlefield 
Operating  Systems  and  their  tasks  (and  subtasks)  are  then  decomposed  into  the 
Action  (physical  processes)  and  Cognition  (decision  making)  components 
described  above.  This  approach  effectively  couples  the  tactical  vocabuUry  of  the 
training  and  doctrine  world  with  an  artificial  intelligence  description  of  the 
objects  on  the  battlefidd.  This  tight  coupling  allows  the  CGF  operators  to  work  in 
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their  normal  regime  of  maps  and  tactical  units  while  accessing  the  full  power  of 
an  Artificial  Intelligence  object  oriented  approach. 

The  specific  BOS  objects  within  a  CGF  Decision  Making  Object  (e.g.  CP) 
interact  by  object  based  message  passing,  analogous  to  manned  vehicle  broadcast 
communications.  Each  BOS  object  is  developed  independently,  and  only  once. 
Different  levels  and  types  of  CGF  Decision  Making  Object  (e.g.  CP)  (including 
distinctions  between  US  and  Threat)  are  implemented  by  data  files  which  control 
eadi  BOS.  Any  CGF  Decision  Maldng  Object  is  implemented  using  the  same 
structure  (as  shown  in  Figure  7)  but  wi^  different  levels  of  logic  and  with 
different  data  specifications  for  each  BOS  object.  Code  is  shared  between  BOS 
components,  reducing  development  time,  costs,  and  risks. 

The  CGF  Decision  Making  Object  has  a  Transport  Relay  Object  for  connectivity 
to  the  DIS  network,  providing  interaction  with  the  rest  of  DIS.  In  addition  local 
copies  of  Battleboard  and  Atmosphere  data  base  objects  are  maintained,  the 
Battleboard  object  being  a  topographical  representation  of  terrain  suitable  for 
automated  reasoning  and  map  like  display.  It  contains  networks  of  linear 
features  (roads,  rivers,  ridge  lines,  valleys  for  example),  area  features  (hills, 
lakes  for  example),  obstacle  breaches  (brieves,  passes,  choke  points  for  example) 
instead  of  the  polygon  lists  contained  in  the  vehicle  terrain  data  base.  The 
Battleboard  and  Atmosphere  objects  are  used  by  the  C2  BOS  to  decide  on 
communications  reception,  and  by  Maneuver  to  plan  movement,  for  example.  An 
Alert  object,  available  to  any  decision  maker,  is  responsible  for  alerting  the 
human  decision  maker  when  a  situatiem  occurs  in  whi(^  the  code  is  incapable  of 
realistic  human  behavior.  This  object  is  extremely  important  and  so  is  discussed 
in  detail  later. 

This  approach  permits  interchangeability  between  human  and  CGF  software 
decision  makers  and  the  generation  of  large  numbers  of  realistic  unit  behaviors 
based  on  combinations  of  a  finite  number  of  BOS  functions  (this  is  due  to  the  many 
ways  functions  and  tasks  firom  different  BOS  can  be  combined). 


4J3L  Tactical  Decision  Making 

CGF  Capabilities  are  the  behaviors  and  reactions  available  to  the  CGF  units 
and  platforms.  These  are  generated  fiom  combinations  of  behaviors  generated  by 
individual  BOS  objects  that  make  up  the  CGF  Decision  Making  Objects,  and 
executed  by  the  human  crew  simulations  using  vehide  characteristics  generated 
by  the  implemented  manned  simulators  specifically  for  CGF  vehides.  The  CGF 
capabilities  are  generically  defined  by  the  capabilities  programmed  into  the  BOS 
objects,  the  complete  set  being  all  feasible  combinations  ^  behaviors  emanating 
firom  each  BOS  for  each  unit. 

The  CGF  Unit  and  Platform  capabilities  and  functions  are  explidtly  modeled 
from  the  TRADOC  Blueprint  of  the  Battlefidd.  This  generates  seven  Battlefidd 
Operating  Systems,  with  subordinate  levd  algorithms  (see  Figure  8  for  a  partial 
enumeration  of  the  behaviors): 

•  Intermediate  level  coordinating  algorithms. 

•  Lowest  levd  behavioral  algorithms. 
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FlgunS  CGF  Behavion  are  constructed  from  TRADOCi  Blueprint  of  the  Battlefield 
by  combining  subfunctions  and  tasks  derived  from  each  of  the  seven  Battlefield 
Operating  Systems.  This  generates  a  large  set  of  flexible  bdiaviors  from  a  constrained 
set  of  well  enumerated  functions.  This  diagram  shows  the  seven  BOS  and  part  of  the 
Maneuver  BOS  down  to  the  behavioral  algorithm  layer.  All  unit  algorisms,  both 
coordinating  and  behavioral,  will  be  implemented  as  CISs. 


The  decomposition  into  BOS  and  subordinate  layers  of  behaviors  generates  a 
militarily  correct  taxonomy  which  maps  into  the  behaviors  of  units  at  each  level 
represented  in  DIS.  This  provides  the  military  user  with  a  familiar  structure  to 
evaluate  the  CGF  behaviors.  Combining  CIS  representii^  these  behavioral  and 
coordinating  algorithms  ensures  doctrinidly  correct  decisions  for  a  wide  range  of 
unit  types  and  battlefield  situations. 

Furthermore,  by  basing  the  CIS  on  the  BOS  taxonomy,  a  common 
representation  of  higher  level  functions  can  be  used  for  both  BLUEFOR  and 
OPFOR.  Combining  &e  functional  CIS  with  different  military  prioritii»,  different 
national  standards,  and  implementing  them  in  different  combinations  under 
different  conditions  allows  explicit  representation  of  different  doctrines  with  a 
minimum  duplication  of  sofWare.  A  small  number  of  algorithms  can  thus 
generate  exceptional  behavioral  flexibiliti^. 

About  twenty  or  thirty  CIS  algorithms  per  BOS  must  be  implemented  for  each 
CGF  type  of  unit  (each  of  which  will  use  different  combinations  of  them).  Since 
there  are  seven  di^rent  Battlefield  Operating  Systems  to  represent  and  several  of 
them  represent  similar  functions,  e.g.  engage  ^gets,  there  are  at  most  200 
algorithi^  to  implement.  Combinations  of  behaviond  algorithms  firom  each  BOS 
with  unit  and  environmental  data  tables  will  modity  the  outcome  and  define  CGF 
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behavior  over  a  wide  range  of  conditions.  Thus  an  enormous  range  of  possible 
behaviors  per  CGF  unit  (representing  the  reality  of  the  battlefield)  can  be  obtained 
finom  a  constrained  set  of  BOS  behaviors. 

4^  Realistic  BelmykHsibrliieCG^ 

All  CGF  objects  are  built  on  combinations  of  doctrinal  Battlefield  Operating 
Systems  (BOSs)  and  their  functions  and  tasks.  Each  of  these  are  further 
decomposed  into  Action  (physical  processes)  and  Cognition  (decision  making) 
components.  The  Action  and  Cognition  components  are  implemented  with  a 
small  number  of  general  functions  whose  con^binations  generate  the  BOS  tasks 
for  the  units  and  the  crew  simulation  behaviors  for  the  platforms.  There  are  only 
a  small  niunber  of  Action  and  Cognition  tasks  (twelve  in  all),  and  so 
implementation  at  this  level  becomes  low  risk.  However,  by  combining  these  tasks 
it  is  possible  to  generate  the  full  range  of  human  behaviors.  CGF  platform  physics 
is  mostly  Action  based,  CGF  crew  simulation  is  a  mix  of  Action  and  Cognition, 
and  CGF  command  posts  are  mostly  Cognition  based. 


FIguieS  Behavioral  Ifaginecringof  the  CGF  in  term*  of  Action  and  Cognition  fonn» 
the  foundatioa  of  the  approach  to  realictk  and  flexible  CGF  bdiavior.  All  objects  in  the 
COF  ardiitecture  are  dmmposed  into  general  Action  and  Cognition  components,  with 
their  general  purpose  tasks.  These  general  tasks  are  combined  to  provide  the  tadcs 
required  by  TRADOCs  definition  of  BOSs  in  the  Blueprint  of  the  Battlefield. 


An  example  of  software  that  successfully  uses  this  form  of  human  behavioral 
engineering  is  the  Simulated  War&re  Environment  Generator  (SWEG)  software 
used  by  the  U.S.  Navy  at  Patuxent  River  Naval  Air  Station  (NAS)  on  the  Aircraft 
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Combat  Environment  Test  and  Evaluation  Facility  (ACETEF)  project  and  by  the 
U.S.  Navy  at  China  Lake  on  research  and  development  efforts.  SWE6  is  a 
successful  implementation  of  the  Action/Cognition  approach,  and  demonstrates 
the  feasibility  of  generating  lai^ge  numbers  of  realistic  and  flexible  behaviors  firom 
combinations  of  small  numbers  of  data  driven  components.  The  Simulated 
Warfare  Environment  Generator  (SWEG)  can  be  used  across  a  wide  range  of 
applications.  It  is  an  example  of  mature  and  robust  simulation  technology,  and 
its  use  in  modules  of  the  CGF  can  be  used  to  prove  the  open  nature  of  the  CGF 
architecture. 

SWEG  controls  the  real-time  operation  of  assets  during  a  test  or  exercise.  An 
asset  represents  something,  part  of  something,  or  several  things,  in  the  exercise. 
An  asset  is  some  combination  of  people,  software,  and  hardware.  A  flight 
simulator  could  be  an  asset.  A  simulation  of  a  JTIDS  communication  network 
could  be  an  asset.  A  simulation  of  a  Combat  Information  Center's  (CIO  data 
fusion  techniques  could  be  an  asset.  SWEG  can  be  configured  to  interface  with 
these  and  other  assets.  The  simulation  portion  of  SWEG  can  also  be  an  asset. 
SWEG  can  exist  on  multiple  computers,  with  each  copy  representing  a  different 
portion  of  the  scenario.  This  allows  the  number  of  entities  in  the  scenario  to 
expand  out  to  the  limits  of  the  communication  links  and  host  computers. 

SWEG  can  represent  anything  in  the  scenario  that  is  not  represented  by 
another  asset.  This  capability  is  useful  during  integration  tests  lea^ng  up  to  an 
exercise.  If  an  asset  is  not  available  during  a  block  of  time,  then  SWEG  can  be 
configured  to  represent  that  asset's  functions,  as  well  as  the  functions  that  SWEG 
would  have  normally.  It  follows,  then,  that  SWEG  can  simulate  the  entire 
scenario,  at  a  reasonable  level  of  fidelity,  in  a  standalone  mode.  In  this  case, 
SWEG  can  run  in  real-time,  at  a  constant  rate  that  is  fiuter  or  slower  than  real¬ 
time,  or  in  a  "go  as  fast  as  you  can"  mode.  When  integrated  with  other  assets 
SWEG  can  run  faster  or  slower  than  real  time,  depending  on  the  capabilities  of 
the  other  assets. 

SWEG  produces,  and  collects  data  firom  other  assets,  that  can  be  sent  to 
SWEG's  graphics  routines  or  other  graphics  packages  for  display  in  real  time, 
near  real-time,  or  in  a  post-exerdse  replay  mode. 

SWEG  is  independent  of  the  computer  host  or  communications  topology. 
ACETEF,  for  example,  is  based  on  shared  memory  for  local  communications 
between  processes,  and  Ethernet  for  communications  between  separated  assets.  It 
used  dedicated  commercial  telephone  lines  with  encryption  devices  to  establish  a 
real-time  link  tvith  the  USAF  REDC^  facility  in  Buf&do,  NY.  Functionally, 
SWEG  sends  and  receives  information  periodically  or  aperiodically.  The  update 
rate  for  periodic  messages  can  be  varied  by  ^q)e  of  message  or  type  of  asset.  This 
eliminates  the  need  for  smiding  everything  at  the  most  firequently  required  update 
rate.  Only  the  interface  o)de  must  be  changed  if  a  new  interface  technique  is 
employed.  SWEG  runs  on  Silicon  Graphics  and  various  DEC  computers  at 
ACETEF. 
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SWEG  uses  DMA  data  for  terrain.  It  represents  signatures  and  antenna 
patterns  in  three  dimensions,  with  user*controlled  variable  amounts  of 
granularity.  It  represents  movement  with  five  degrees  of  freedom  (velocity  is 
oriented  idong  the  longitudinal  axis  of  the  vehicle).  It  is  expected  that  this 
limitation  will  disappear  within  the  next  year.  Tactics  and  doctrine,  command 
chains,  and  related  aspects  are  contained  in  the  data.  SWEG  makes  no  C3 
assumptions.  Likewise,  weapon  systems,  jammers,  sensors,  movement 
capability,  and  communication  systems  are  defined  in  the  data,  not  in  the  code. 
Sl^G  will  perform  flat  earth,  curved  earth,  and  effective  earth  radius  calcu¬ 
lations  depending  on  the  ffie  user’s  data,  by  type  of  system,  for  all  energy-related 
calculations. 

4.4.  CGFFlatfonnOlgectB 

All  CGF  platform  types  will  be  based  on  a  modular  platform  simulation 
containing  two  subcomponents:  the  platform  object  which  handles  action  items 
such  as  weapons,  dynamics  and  kinematics;  and  the  crew  object  which  simulates 
crew  decision  making.  The  platform  action  object  code  will  consist  of  modified 
versions  of  the  MODSIM  algorithms  used  by  the  DIS  manned  vehicle  simulators 
(for  example,  CGF  platforms  do  not  need  detailed  internal  models  of  the  engine) 
driven  by  data  tables.  Where  a  manned  vehicle  simulator  is  not  available  as  a 
basis  for  a  CGF  platform,  the  CGF  will  provide  the  MODSIM  equivalent 
algorithms.  The  data  tables  required  to  drive  CGF  platforms  not  represented  by 
manned  simulators  will  be  provided  by  empirical  data  drawn  from  combined 
arms  and  joint  tests.  It  is  these  data  tables  that  provide  the  physical  fidelity. 

All  input/output  to  the  human  crew  is  replaced  with  a  CGF  crew  simulation. 
The  CGF  crew  simulation  is  based  on  the  same  structure  as  the  CGF  decision 
making  object,  being  divided  into  battlefield  operating  systems.  The  BOS  for 
platform  crew  will  be  much  simpler  than  those  for  unit  CPs  and  will  be  generated 
firom  a  simpler  set  of  the  same  BOS  cognition  structures.  The  crew  simulation 
wfll  command  and  control  the  platform  using  CISs  passed  through  the  tactical 
communications  simulation.  The  MODSIM  equivalent  algorithms  will  execute 
the  move,  shoot,  communicate  and  see  actions.  Data  ^es  distinguish  each 
platform  by  type,  capability,  and  color  (US,  Russian,  or  other  threat). 
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Figure  10  The  CGF  Platform  Simulatioa  object  uses  kinematics,  dynamics, 
vulnerability,  and  damage  data  from  the  manned  simulators  running  on  modified 
manned  simulator  algorithms.  When  a  manned  simulator  version  of  a  required  CGF 
platform  is  not  available,  then  empirical  data  from  joint  tests  is  used.  A  CGF  human 
crew  simulation  replaces  I/O  to  the  human  crew,  and  is  based  on  the  modular  BOS 
approach  to  the  CGF  CP. 


45.  Tactical  Communicatioiis  Simiilntimi 

An  extremely  important  part  of  the  CGF  is  the  simulation  of  tactical 
communications,  which  is  at  the  heart  of  intelligent  cooperative  battlefield 
behavior.  In  order  for  the  CGF  to  behave  realistically  at  the  unit  level  it  is 
necessary  to  simulate  the  flow  of  information  and  orders  through  the  command 
hierarchy.  This  has  the  added  advantage  of  allowing  jamming,  terrain  masking 
and  atmospheric  effects  to  interfere  with  the  flow  of  communications,  thus 
generating  realistic  confusion  and  delays  (i.e.  the  fog  of  war).  Seamless 
Simulation  issues  such  as  electronic  warfare  using  operational  eqmpment 
integrated  with  DIS  become  possible  only  if  the  CGF  explicitly  simulates  the 
tactical  communications  contained  within  the  C2  BOS.  Thus  the  CGF  software 
decision  makers  will  communicate  with  each  other,  with  the  human  operators, 
and  with  their  subordinate  platforms  via  an  explicit  simulation  of  tactical 
communications  contained  within  the  Command  and  Control  (C2)  Battlefield 
Operating  System  (BOS)  (see  Figures  3,  7  and  11). 

CGF  generated  tactical  communications  must  be  receivable  by  other  CGF 
units  (operated  by  humans  or  by  software).  The  CGF  Tactical  Communications 
architecture  supports  direct  human  to  CGF  software  tactical  communications 
though  the  use  of  text  generation  from  data  structures,  speech  generation  from 
text,  and  speech  recognition  (see  Figure  11).  The  DIS  Message  Standards  must 
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include  data  representations  within  the  radio  message  packet  in  order  to  support 
CGF  communications. 


1:  Input  forms  and  graphics 

2:  Radio  message  generation  •  text  generation  from  data  structures 

3:  Radio  message  generation  -  digitised  speedi  generation  from  text 

4:  Radio  jamming  •  generate  data  structure  and  digitized  noise 

5:  Receive  /  No  receive  decision 

6:  Speech  recognition  and  understanding 

Figure  11  The  CGF  Tactical  Communicationa  Simulation  handles  communications 
from  CGF  to  CGF  and  to  manned  simulators.  Speech  generation  from  data  by  the  CGF  is 
recommended  rather  than  generation  by  the  receiver  nodes  since  this  permits  older 
platform  simulators  to  receive  CGF  transmissions  without  requiring  upgrades  with 
speedi  generation  technology.  This  however  is  a  trade-cIT  between  increased  data  rates 
on  the  networks  created  by  CGF  speech  generation  versus  technology  iqigrades  of  all 
platform  simulators. 


4.6.  Alert  Agent 

However,  for  reasonable  expenditures  of  resources  there  will  always  be  cases 
where  CGF  software  is  faced  with  situations  it  is  unable  to  handle  in  a  tactically 
realistic  fashion.  The  traditional  approach  to  this  problem  in  the  CGF  has  b^n  to 
rely  on  the  operator  to  monitor  all  CGF  units  and  platforms,  and  to  immediately 
intervene  when  necessary.  One  result  of  this  is  that  the  human  commander  is 
often  overloaded  by  the  CGF.  This  problem  will  get  worse  as  the  CGF  expands  into 
higher  echelons,  and  more  layers  of  CGF  software  exist  between  the  human 
commander  and  the  platform  level  of  interaction.  The  behavioral  engineering 
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approach  recommended  by  the  step  1  study  will  reduce  the  frequency  of  such 
required  interventions,  but  will  not  remove  them  completely.  Indeed,  it  is  doubtful 
that  complete  removal  is  advisable,  as  the  CGF  is  oonsiderably  enhanced  by  the 
insertion  of  human  ingenuity  via  the  intervention  mechanism. 

The  CGF  Alert  Agent  avoids  operator  overload  in  the  face  of  unavoidable 
software  requests  for  human  intervention.  In  a  complex  and  time  sensitive 
tactical  situation,  e.g.  where  a  CGF  unit  is  being  overrun,  the  CGF  unit  will 
respond  tactically  using  the  communications  simulation.  At  this  time  the 
operator  has  the  option  of  intervening  as  he  would  on  the  real  battlefield,  or  letting 
the  situation  nm  its  course.  The  CGF  alerts  system  requests  human  control  when 
parametrically  defined  triggers  fire  (e.g.,  casualties  high,  rates  of  advance  low). 
The  operator  can  opt  for  the  default  alert  setting  or  ra^  order  them  in  levels  of 
priority.  The  operator  also  sets  the  alert  interface  to  control  volume  of  incoming 
alerts.  On  the  other  hand,  if  the  situation  becomes  too  complex  for  the  code,  then 
the  CGF  code  recognizes  that  it  has  no  valid  default  CIS  and  immediately  alerts 
the  human  operator  for  help  in  order  to  avoid  compromising  the  exercise.  In  this 
case  the  operator  has  the  option  of  an  immediate  intervention  by  bypassing  the 
Tactical  Communicationa  simulation.  This  new  CGF  capability  (code  that  can 
identify  when  it  cannot  handle  a  situation)  is  handled  by  an  object  called  the  Alert 
Agent.  It  is  a  simple,  extendible,  and  powerful  technique  available  to  all  BOS 
objects. 

Alerts  to  the  operator  are  thus  minimized,  and  under  user  control.  The  user 
can  tailor  the  alert  system  to  focus  on  spedfic  units,  events  or  interactions 
according  to  his  preferences.  Furthermore,  the  alert  agent  is  used  to  automate  the 
identification  and  logging  of  situations  in  which  the  CGF  code  cannot  behave  with 
realisticaUy,  thus  provi^og  valuable  support  for  system  upgrades. 

All  CGF  units  operate  autonomously  as  the  default.  Each  CIS  being  executed 
by  a  CGF  imit  carries  parameters  (for  example  a  doctrinal  advance  rate  for  an 
attack).  When  the  alert  filter  detects  actiud  situation  parameters  are  out  of  range 
of  desired  parameters  (for  example  actual  rate  of  advance  is  below  doctrinal  or 
ordered  rate)  an  alert  is  generate,  rank  ordered,  and  passed  to  the  operator  or 
dropped  depending  on  the  threshold  requested  by  the  operator.  All  CISs  will  have 
alert  filters  associated  with  them,  not  just  the  examples  indicated  in  this 
diagram. 


Mafvii81,19fa 


108 


AD8T/WDL/ra~92-00S010 


•nt 


bamplM  €l  pomM* 
alwtMlara 


ti 


ffOF  Ptflitten  Khlttf 


bail  ynP  Mi  uril  lyp* 
aMlMMbM 


Figiml2  Tlie  CGF  Alert  Agent  integrates  tiMautonomoui  and  human  control  of  CGF 
units,  providing  a  shared  initiative  system  with  significant  enhancement  to  CGF 
realism  and  reduction  in  operator  loading. 


4.7.  Senior  QjommanderSiqjpoirt  Tools 

I 

The  C2  BOS  also  contains  planning  tasks  such  as  Course  of  Action  (COA) 
Evaluation.  A  CGF  simulation  system  ^ua  has  to  emulate  the  COA  evaluation. 
i.e.  provide  an  emulation  of  the  branch  waxgaming  carried  out  by  the  G2  and  G3. 
The  COA  evaluation  is  a  faster-than-real*time  approximate  simulation  of  the 
perceived  situation,  and  should  be  provided  as  part  of  the  CGF  architecture.  Since 
the  CGF  human  commander  will  have  access  via  the  user  interface  to  all  BOS 
simulations,  this  will  provide  the  commander  with  a  faster  than  real  time 
planning  and  evaluation  tool  for  pre-battle  as  well  as  battle-time  planning. 

The  structure  of  the  CGF  decision  making  object  (as  exemplified  in  the  CGF 
Command  Post  Simulator)  directly  supports  faster  than  real  time  wargaming  at 
the  unit  level  to  provide  planning  support  to  the  human  trainees  prior  to  an 
engagement.  Every  CGF  Command  Post  has  an  embedded  C2  BOS,  which  itself 
contains  the  subfimctions  "develop  couxses  of  action",  "analyze  courses  of  action", 
"compare  courses  of  action",  and  "select  or  modify  course  of  action".  These 
sifofimctioxis  collectively  are  the  wargaming  process  by  which  the  comxnander  (or 
his  sta^  evaluate  courses  of  action  and  xna^  their  recoxmnendatioxxs.  The  CGF 
simulator  will  emulate  this  process  in  the  C2  BOS,  and  this  BOS  is  available  for 
control  by  tibte  CGF  conuxiander.  The  waxgamixig  process  in  the  C2  BOS  is  a  faster 
than  real  time  simulation  of  the  DIS  battlefi^d  at  the  unit  level  of  aggregation,  the 
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level  of  aggregation  being  one  and  two  levels  below  the  command  level  of  the 
command  post  Tlie  CGF  commander  is  permitted  by  the  CGF  system  to  take  over 
direct  control  of  any  subordinate  unit  and  hence  can  wargame  at  any  level  of 
detail  for  all  subordinate  units  down  to  the  vehide  level. 


TaeCemins 

Simulation 


Ordors 


I 

Information 
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Roquosta 


PartofOGFC2B08 


BDE/REGT  Branch  Wargame 


Comparoa 

Contrast 

COCOAS 


BN  Branch  Wargame 


CO  Branch  Wargame 


Part  of  OOF  HM 


CGF  BN 


BDS-D 
CGF  CO 


FignrelS  fiowW  ramiMiiHjiy  PtaimfwgTnnla  ar«  availaMa  from  tha  BOS  baaed  AGP 
Command  Post.  For  szampls,  the  C2  BOS  contains  an  emulation  of  the  course  of  action 
evaluation  process  whidt  is  available  to  the  CGF  commander  via  the  MMI. 


4A  Userlnterfieuses 


The  CGF  must  support  two  broad  uses.  First  it  must  provide  a  component  of 
the  DIS  environment  for  human  CGF  commanders  as  warfighters  "fighting  to 
win".  In  this  use,  the  CGF  is  a  tactically  realistic  user  interface  into  the  DIS  for 
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militazy  commanders.  Second  it  must  provide  control  of  the  DIS  environment  for 
trainers  and  analysts  by  generating  and  manipulating  the  CGF.  In  this  use  the 
CGF  becomes  a  tool  for  direct  manipulation  of  the  dS  environment  Both  these 
uses  must  be  supported  by  the  same  user  interfaces  and  simulation  system, 
without  requiring  complex  restructuring  of  the  CGF  system  when  switching 
between  uses.  Fiurthermore,  the  user  interface  must  permit  the  operator  to  take 
command  of  any  software  decision  making  node  within  the  simulated  C3I 
hierarchy  of  the  CGF.  Plug-in  compatibility  between  operator  and  software  is 
required  to  provide  a  flexible  insertion  of  human  ingenuity  without  overloading 
the  operator  or  generating  areas  of  the  CGF  which  are  outside  human  control. 

The  difference  between  the  tasks  of  the  Warfighter  "fighting  to  win"  and  the 
Analyst/Trainer  "controlling  the  environment"  are  characterized  by  the  degree  of 
penetration  into  ground  truth  and  the  degree  of  control  over  the  environment,  as 
shown  in  Figure  14.  The  Warfif^ter  perceives  the  DIS  battlefield  and  controls  his 
forces  through  a  Tactical  Communications  simulation  system  with  realistic 
unreliability  and  by  moving  aroimd  in  a  manned  simulator  vulnerable  to  combat 
damage.  The  Trainer/Analyst,  however,  has  perfect  Tactical  Communications, 
can  exercise  immediate  intervention  in  controlling  CGF  forces,  and  can  travel  the 
DIS  battlefield  in  the  on-screen  Stealth  Vehicle.  These  very  different  working 
environments  can  be  distinguished  entirely  by  providing  each  with  different 
privileges  and  levels  of  control  over  the  Tactical  Communications  simulation  and 
the  Alert  Agent  components  of  the  user  interface.  The  warfighter  has  to  use  the 
complete  tactical  communications  simulation,  with  realistic  delays,  jamming, 
lost  messages  etc.,  in  order  to  communicate  with  and  control  his  forces,  and  he 
has  restricted  access  to  the  alert  agent.  The  trainer/analyst  however  is  granted 
perfect  tactical  communications  with  immediate  and  perfect  message  delivery, 
and  has  access  to  a  complete  alert  agent  with  full  immediate  intervention 
privileges 

In  addition,  the  Trainer/Analyst  is  provided  a  Stealth  and  Plan  View  Display 
while  the  Warfighter  uses  manned  platform  simulators  and  simulated 
intelligence  displays.  This  increases  the  flexibility  of  the  overall  DIS  CGF  system 
since  with  the  proper  password  and  initialization  data  the  same  CGF  system  can 
serve  dual  purposes.  The  use  of  a  common  MMI  with  identical  maps,  screens, 
and  windows  (with  some  functions  simply  restricted  to  one  type  of  operator) 
ensures  that  a  consistent  MANPRINT  standard  is  used.  The  common  kOdI  also 
reduces  the  effort  to  develop,  mflintnin,  and  '  nhance  separate  screens. 
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ngme  14  The  CGF  Architecture  Supports  Dual-Use  by  using  different  access 
privileges  to  the  same  user  interface  components.  This  ensures  that  duplication  of  effort 
does  not  occur  when  supporting  different  user  types 

The  MMI  screens  should  be  developed  using  a  commercially  available 
Graphical  User  Interface  (GUI)  builder,  and  should  use  COTS  producst  such  as 
X  windows  and  Motif  for  portability.  An  open  approach  to  interfodng  the  MMI 
screens  with  the  underlying  CGF  functionality  will  permit  development  of  the 
MMIs  separate  from  tiie  rest  of  the  CGF,  and  will  facilitate  the  future 
development  of  specialized  MMIs  for  particular  end-users  who  may  wish  a 
different  MMI  for  their  purposes  (although  we  ezpect  that  most  users  will  be 
satisfied  with  the  ability  to  alter  the  MMI  via  privilege  control  as  discussed). 

MMIs  should  be  developed  in  com’unction  with  Subject  Matter  Experts  (SMEs) 
so  that  the  MMI  accurately  reflects  what  will  be  most  efifective  in  real  world  use. 
Consultation  with  these  SMEs  will  also  ensure  that  privileges  and  displays  are 
proper  for  the  type  of  user  (e.g.  Warfighter  vs.  Trainer). 

Multiple  tactical  units,  BOSs  and  platforms  (as  well  as  Battleboard  or 
Atmosphere  objects)  can  be  presented  to  a  single  operator  for  monitor  and  control 
(depending  on  operator  loading  constraints),  but  each  such  object  can  have  only  a 
single  human  controller  (see  Figure  15).  Each  CGF  unit  attached  to  a  specific 
curators  Man-Machine  Interface  (MMI)  has  logical  links  to  one  or  more  BOS 
objects.  At  an  operator  request,  each  unit  or  BOS  can  disiday  its  state  and  the  state 
of  its  subordinates  either  as  seen  fimm  its  CP  object  (perceived  truth)  or  firom  the 
platform  objects  (ground  truth). 
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Ftgnre  15  CGF  Operator  InterCMM  allow*  the  operator  to  interfiMe  to  any  BOS  in  a  CXIF 

Unit  for  direct  control  or  luperviaion. 


Human  CGF  operators  will  input  orders  and  messages  to  CGF  units  at  any 
echelon  via  the  using  map  graphics*  menu  selections  and  and  forms.  The 
MMI  will  translate  these  into  ^e  internal  machine  representation  of  the  CISs. 
Alternatively,  CGF  software  wUl  generate  the  CIS  internal  representation 
directly.  Both  processes  generate  ra(ho  message  which  are  passed  to  the  tactical 
communications  simulation  within  the  C2  BOS  for  simulated  transmission  over 
the  BDS-D  network  in  the  form  of  DIS  PDUs  containing  the  CIS  structures.  At  the 
receiver,  a  receive/no  receive  decision  will  be  made  based  on  transmission  and 
receiver  characteristics  and  intervening  terrain  and  atmospheric  conditions.  If  a 
receive  decision  is  made,  then  the  receiving  CGF  software  operates  directly  on  the 
CISs,  and  any  MMI  at  that  location  translates  the  CISs  into  the  map  graphic  and 
tezt/forms  representation  for  the  human  operator  (see  Figure  11).  Tlie  CGF 
operator  has  the  option  to  enforce  the  immediate  arrival  of  a  message  to  provide 
dinMTt  control  of  a  vehide  or  to  ensure  that  a  command  is  acted  upon  by  a  hi^^ier 
echelon  unit. 


5  Potential  Additional  Areas  of  Researdi 


The  CGF  system  must  be  capable  of  easy  upgrade  and  expansion,  and  it  must 
be  implemented  such  that  new  requirements  and  technologies  can  be  inserted. 
The  structure  of  the  recommended  CGF  architecture  easily  permits  such 
extensions  because  of  its  modular  structure  and  the  data  dominant  nature  of  the 
software  which  allows  many  changes  to  be  implemented  in  data  with  minimal 
software  changes.  Figure  16  provides  an  overview  of  potential  future 
requirements,  the  associated  technology  extensions,  and  the  specific  action  which 
will  be  taken  with  CGF  to  support  implementation  of  the  technology  extensions. 
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.cFigure  16  CGF  TtrimologyEatenakiMaiw  driven  by  teurePlSrequirBmBnla;  and  are 
supported  by  the  CGF  structure.  In  particular,  all  BOS  simulations  are  constructed 
independently  and  can  thus  be  upgraded  by  different  users.  The  Tactical 
Communications  simulation  permits  speMh  recognition  extensions,  and  upgrades  to 
intelligence  and  electronic  wariare,  by  integration  with  (^rational  equipments. 

A  m^jor  technology  extension  for  the  CGF  are  fully  autonomous  C3I  BOS 
objects,  thus  supporting  integration  of  human  and  software  decision  making  at 
all  levels  of  command  and  control  including  at  the  platform  level.  A  critical 
element  of  this  is  the  ability  of  CGF  software  to  receive  and  respond  to  radio 
xnessages  from  manned  simi;^tors  and  command  elements.  This  is  only  possible 
with  the  incorporation  o£  speech  recognition  and  analysis  algoritlmis.  The  CGF 
ardntecture  supports  the  incorporation  of  these  tMhnologies  into  the  CGF 
Tactical  Communications  Simulation  as  shown  in  Figure  11. 
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6  Step  1  Task  1  Study  ConduidoiM 

The  Computer  Generated  Forces  is  a  necessary  and  critical  component  of 
BDS-D.  It  is  required  to  provide: 

•  large  munbers  of  DIS  forces  with  low  manpower  requirements. 

•  simulation  of  the  performance  and  appearance  of  manned  simulators. 

•  simulation  of  the  performance  and  appearance  of  platforms  for  which 
no  manned  simulators  exist. 

•  simulation  of  human  decision  making  in  a  simulated  C3I  hierarchy. 

•  user  interfaces  to  any  decision  making  node  in  the  simulated  C3I 
hierarchy  for  the  CGF. 

•  provide  credible  and  realistic  large  scale  battlefield  behaviors. 

It  is  currently  treated  as  a  single  large  system,  implemented  by  a  single 
developer.  The  CGF  however  is  sufficiency  large  and  complex  t^t  it  warrants  its 
own  architecture  with  components  capable  of  independent  development, 
modification,  and  expansion  by  multiple  users.  Such  an  architecture  will 
decouple  the  risks  associated  with  each  technical  area  of  the  CGF,  and  permit  a 
reconfigurable  CGF  capable  of  changes  without  the  migor  rewrites  t^t  have 
plagued  the  current  system.  Furthermore,  most  DIS  participants  will  want  to 
insert  their  systems  into  a  large  scale  and  rich  simulated  battlefield  environment, 
but  will  not  ^ve  the  resources  to  provide  that  environment.  Therefore  the  step  1 
study  determined  that  the  Computer  Generated  Forces  is  an  integral  part  of  the 
DIS  infirastructure,  and  is  thus  part  of  the  DIS  architecture. 

The  CGF  architecture  miut  provide  within  a  modular  and  open  system  user 
interfaces  for  different  purposes  (developers/modifiers,  warfighters, 
trainer/analysts,  et  cetera),  realistic  battlefield  ^haviors,  and  expandability  in 
scale,  scope  and  realism.  The  critical  technical  problems  are  to  provide  general 
models  of  human  battlefield  behavior  winch  can  be  combined  into  reconfigurable 
models  of  battlefield  functions  without  the  risks  normally  associated  with 
attempting  to  simulate  human  behavior.  These  models  must  generate  credible 
and  realistic  behavior,  and  be  scaleable  to  large  battlefields  without  prohibitive 
personnel  or  hardware  costs.  The  architecture  must  be  such  that  the  government 
can  call  upon  multiple  independent  developers  (industrial,  academic,  military 
and  government  teams)  to  develop,  modify,  expand  and  maintain  the  CGF 
components.  It  shoidd  make  maximum  use  of  current  industry  standards,  and 
avoid  as  much  as  is  possible  unique  solutions  and  technologies. 

The  CGF  Architecture  must  support  the  operational  objectives  of  the  CGF  and 
deal  with  the  problems  identified  by  the  step  1  study.  The  step  1  study  concluded 
that  a  modular  CGF  architecture  is  feasible,  and  recommend  that  a  proof  of 


UUP 

concept  be  built  whose  goal  is  to  draionstrate  an  effective  CGF  capable  of  modular 
and  open  implementation  and  modification.  Within  tlm  overall  goal  of  providing  a 
modular  and  open  CGF,  the  following  components  of  an  architecture  are  viewed 
as  critical  in  order  to  deal  with  the  problem  areas  identified  by  the  step  1  study: 

•  User  Interfaces 

•  Realistic  CGF  Behaviors 

•  Alert  Agent  for  the  CGF 

•  Incorporation  cf  all  Battlefield  Functions  for  all  Services 

•  Modular  transition  to  Ada 

•  Integration  with  Higher  Order  Models 

•  Distributed  CGF 

•  Senior  commander  decision  support  tools 

•  Adaptive  CGF  behaviors 

The  Step  1  Study  recommends  that  the  CGF  architecture  is  implemented  in 
two  nugor  phases  in  order  to  control  the  impact  of  the  CGF  on  the  DIS  message 
protocol  standards.  In  Phase  1  the  CGF  decision  nodes  are  implemented  in  an 
object  oriented  fashion  (based  on  the  BOS  objects),  with  each  decision  node  an 
entity  whose  internals  (the  BOSs)  are  private  as  far  as  the  DIS  network  is 
concerned.  The  DIS  message  standard  must  be  extended  to  handle  data 
structures  within  the  radio  message  padcet,  thus  permitting  CGF  to  transmit  and 
receive  simulated  radio  messages.  In  Phase  2  the  CGF  BOS  objects  are  distributed 
over  the  DIS  networks,  thus  permitting  geographically  distributed  BOS  developers 
and  users  to  combine  their  objects  into  CGF  de^on  nodes,  hi  this  phase,  the  DIS 
message  standard  must  be  extended  to  handle  inter>BOS  coommunications, 
which  simulate  face-to-face  human  communications. 
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